[gmpi] Re: Reqs 3.8 Events - gesture start/end
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 30 Dec 2003 21:24:30 +0100
On Tuesday 30 December 2003 19.57, Paul Davis wrote:
> >There are (at least) two perfectly logical ways of thinking about
> >event handling:
> >
> > 1. Events are to be processed in the order received,
> > and the processing is to be done directly as the
> > events are decoded. Event ordering is sort of the
> > "fractional part" of the timestamps, in that
> > ordering of events with the same timestamp may
> > matter.
> >
> > 2. Events are to take effect at the audio time
> > indicated by their timestamps. Ordering of events
> > with the same timestamp is irrelevant. Plugins
> > must act as if events with the same timestamp
> > are processed at the exact same time.
> >
> >
> >IMHO, the second view is the appropriate one for control events in
> > a DSP plugin system. It's the default behavior of any plugin
> > where control events just change variables used by the DSP inner
> > loop. Simulating that behavior where controls become
> > interdependent outside the DSP inner loop is most definitely
> > cleaner and simpler than anything that requires senders to figure
> > out the correct order of control events with the same timestamps.
> >
> >
> >As to the term "gesture" used as "control change group", you could
> >think of every audio sample frame as one implicit gesture. Any
> > group of events with the same timestamp are to be considered as
> > simultaneous WRT their effect on the signal processing.
>
> i see no way to handle this without ensuring that there is a clear
> way for the plugin to see the beginning and end of events to be
> processed before the next process() call. some designs that have
> been proposed in various places would do this implicitly, others
> would not. the plugin has to be able to know that a parameter
> change to Foo is or is not going to be followed by a simultaneous
> change to Bar. no other design will be sufficient, IMHO. as long as
> we make this possible, things will work, i think.
I'm not quite sure how you would go about *not* making this possible,
and still have a working event system, but I'm probably forgetting
something.... (Asynchronous event delivery? Can't work properly
anyway, so it's irrelevant, IMHO.)
I think you have to be able to tell whether there are more events for
*each frame*; not just for the current process() call. Processing
timestamped events can be done something like this:
For each sample frame in the buffer:
{
If there are any events for this frame:
{
For all events for this frame:
{
Process this event.
}
Perform any calculations involving
multiple interdependent controls.
}
Process audio for this frame.
}
In real code, you don't actually check for events once for each sample
frame, but that doesn't change the fact that you will have processed
all events for each sample frame before you start processing the
audio.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
