[LAD] "enhanced event port" LV2 extension proposal

Dave Robillard drobilla at connect.carleton.ca
Sat Dec 1 21:09:19 UTC 2007


On Sat, 2007-12-01 at 21:49 +0100, David Olofson wrote:
> On Saturday 01 December 2007, Dave Robillard wrote:
> [...]
> > 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.

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-





More information about the Linux-audio-dev mailing list