1 Dec
2007
1 Dec
'07
5:09 p.m.
On Sat, 2007-12-01 at 21:49 +0100, David Olofson wrote:
On Saturday 01 December 2007, Dave Robillard wrote:
[...]
Obviously MIDI-like events to be handled in-band in the audio stream
would use frame time stamps, yes.
You can't do everything with in-band realtime events though... say,
firing around video frames in events for processing (not at all unheard
of in pd etc). You can't be doing complex image processing in the audio
thread, that's idiotic. ie yes this is a wider scope for events, but
it's necessary.
I'd rather not go on this digression to be honest, multi-context
plugins/patcher environments with events crossing contexts is not a
trivial subject. The time stamps being up to the task would sure be
nice though...
All I ask for is a few measley bits :) That I can point to widely
accepted standards (one of which is very, very close in domain to this
event stuff) that use timestamps of this sort is telling..
Anyway, making the frames part 16 bits screws up parity with Jack MIDI.
We already have a uint32_t frame timestamp. We want fractional, so
stick a fractional part in there, voila. The host just sets the
fractional part to 0 from Jack, things can use the fractional bit (or
not) as they please.
Simple.
-DR-
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.
[...]
I'm not sure about the scope of this LV2 event system, but the idea of
using timestamps related to anything other than audio time (ie
buffers, sample frames etc) seems to be a violation of the idea that
events are essentially structured control data or similar - ie
anything that's "locked" to the audio stream.