Subject: Re: [linux-audio-dev] XAP and Event Outputs
From: Tim Goetze (tim_AT_quitte.de)
Date: Wed Dec 11 2002 - 19:54:49 EET
David Olofson wrote:
>On Wednesday 11 December 2002 15.25, Tim Goetze wrote:
>> David Olofson wrote:
>> >So, sort them and keep track of where you are. You'll have to sort
>> >the events anyway, or the event system will break down when you
>> > send events out-of-order. The latter is what the event processing
>> > loop of every plugin will do, BTW - pretty trivial stuff.
>>
>> what you describe here has a name: it's called queuing.
>
>Of course. But it doesn't belong in the event system, except possibly
>as a host or SDK service that some plugins *may* use if they like.
>Most plugins will never need this, so I think it's a bad idea to
>force that overhead into the basic event system.
above, you claim that you need queuing in the event system,
and that it is 'pretty trivial stuff', in 'every plugin'.
now you say you don't want to 'force that overhead'.
>> >Do event processors posses time travelling capabilites?
>>
>> delays based on musical time do, whatever you like to call
>> it.
>
>Then they cannot work within the real time net. They have to be an
>integral part of the sequencer, or act as special plugins for the
>sequencer and/or the editor.
so eventually, you'll need a different event system for
plugins that care about musical time. and what if you come
to the point where you want an audio plugin that needs to
handle musical time, or prequeued events? you'll drown in
'special case' handling code.
i'm convinced it's better to design one system that works
for event-only as well as audio-only plugins and allows for
the mixed case, too. everything else is an arbitrary
limitation of the system's capabilities.
using audio frames as the basic unit of time in a system
producing music is like using specific device coordinates
for printing. they used to do it in the dark ages, but
eventually everybody agreed to go independent of device
limitations.
tim
This archive was generated by hypermail 2b28 : Wed Dec 11 2002 - 20:01:04 EET