1 Dec
2007
1 Dec
'07
6:10 p.m.
On Sat, 2007-12-01 at 14:56 -0500, Dave Robillard wrote:
No argument that it's faster. With separate int
fractional parts it's
even probably cleaner. I may be convinced...
Taking a step back, it would be nice to have these events (being
generic) able to use something other than frame timestamps, for future
dispatching/scheduled type event systems. OSC uses 64 big fixed point
absolute time stamps, giving a resolution of about 200 picoseconds
absolute time (epoch January 1, 1900). This is equivalent to NTP time
stamps apparently - ie huge precedent.
Whether stamps are in frames or absolute time could be a property of the
port. Maybe we should up it to 64 bits fixed point? The additional 32
bits aside, doing that gives us all the range or precision in frames
needed, and the ability to map to a widespread absolute timestamp
format, and parity with OSC. That's a lot of pros...
(This may sound a bit esoteric, but to do something like Max right, you
need absolute time stamps).
Currently in MIDI we have 64 bits in there anyway.. I never thought of
using fixed point, but the OSC/NTP parity and potential for very precise
absolute time stamps is very, very tasty to me.
Also, the frame part would be a uint32_t - equivalent to Jack MIDI
timestamps, another win (and cutting out more conversion overhead).
Another thought on 32:32 fixed point with a 'timestamp type' concept:
tempo time.
You could use these stamps at beats:ticks time stamps with excellent
range/resolution. Actually now that I think of it I've run into exactly
this problem in Ardour MIDI with floating point tempo-time-stamps.
32:32 stamps like this would be excellent in a sequencer, I would
definitely use them in Ardour.
With the same event struct we can get:
- Sub-sample accurate frame timestamps (Jack MIDI stamps + resolution)
- Absolute timestamps with sub-nanosecond resolution (OSC equivalent)
- Tempo relative timestamps with much higher resolution than any
existing MIDI/sequencer/etc gear I know of
++
-DR-