[gmpi] Re: Reqs 3.8 Events - gesture start/end

On Tuesday 30 December 2003 14.02, Paul Davis wrote:
> >On Mon, Dec 29, 2003 at 08:37:07 -0500, Paul Davis wrote:
> >> however, going a step further, michael reminded me of XY pads.
> >> anytime the control device sends two parameters as part of a
> >> single message, we have something that is very close to,
> >> gestural. consider a simple XY pad. each message it transmits
> >> contains 2 pieces of information that could be used to control
> >> two parameters independently, yet the message arrives
> >> "atomically", so you effectively changing two parameters at the
> >> same time. all the same, you can do this with the slider too,
> >> just map two parameters to the same control point.
> >
> >The events would just arrive with the same timestamp, and so be
> > processed in the same k-step.
>
> yes, i recognize this. but the parameter setting may be subject to
> some level of interpretation by the plugin - it may be that setting
> Foo and then setting Bar is different than setting Foo and Bar
> simultaneously. Consider the godawful mess with 14 bit MIDI
> messages, where you don't know what to do with the first nibble
> without adding a timeout to see if the second nibble is coming. By
> bracketing the Foo+Bar pair, the plugin can know "ok, Foo is being
> set now but more parameter events are coming".

This sounds a bit related to what we eventually called "latched 
controls" in XAP; controls that maintain values that are only 
considered ("latched") when certain state changes occur. State 
changes, in turn, are triggered by well defined changes in other 
controls. For example, MIDI style NoteOn velocity would be a latched 
control whose value is read only when the GATE control switches to 
"on".

IIRC, we concluded that the only sane and reliable way to get this 
right was to define the relation something like this:

        * The value of a latched control must be set at or
          before the sample frame during which the latching
          state change occurs.

Note that this does *not* mean that the events setting the values of 
latched controls must arrive before the event that causes the state 
change! Plugins are required to do the right thing even if the state 
change event arrives before the control events.

In implementation terms, this means that the actual control latching 
and state changing occurs after all events for a sample frame have 
been processed, right before the audio processing for that frame is 
done.

This might seem to complicate things for receivers using latched 
controls - but consider the implications of requiring senders to sort 
seemingly unrelated events according to rules defined by the 
connected receivers!


There is another issue we ran into, that is also related to the order 
of control changes: Preset loading. If plugins are allowed to react 
differently depending on the ordering of events sent with the same 
timestamp, there is no safe way to restore saved states using the 
controls.

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.


//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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: