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- _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev