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

On Tuesday 30 December 2003 23.13, Chris Grigg wrote:
> Please forgive a question about one thing I don't understand about
> the concept of plugs being 'gesture-aware'.
>
> Assume that a given target (parameter, control, whatever
> terminology) in a given plug instance is being driven by a series
> of
> live-performed events from a HW control surface, bookended with
> 'gesture-start' and 'gesture-end' events; also assume that the plug
> knows how it wants to handle the events within the gesture to make
> sense out of them (correlating to another target's value, value
> filtering/smoothing, or otherwise transforming in some manner). 
> Now, what if some other rogue event source (maybe a sequencer
> track, etc.) is also sending events to the very same target, i.e.
> there's a second series of incoming events having no relation to
> the gesture being performed on the live control surface.

That would be illegal, unless we come up with a horribly complicated 
connection system. A control input can only be connected to one 
control output at a time. If you have multiple sources, you need some 
device that combines inputs, switches between inputs or does 
something else that makes sense, to generate a single output stream 
of events.


> Won't
> this blow the plug's gesture processing out of the water?

Depends on whether it's designed for multiple connections per input, 
but I don't see how that could be done in a sensible and useful way. 
Just use multiple inputs, if that's what you want. (You might, if 
you're an automation sequencer, for example.)


> Putting the question another way: Does making plugs gesture-aware
> necessitate either a) Adding a host-side target exclusivity/locking
> mechanism to avoid interference with the gesture processing,

No, because selecting which sender gets through is up to the host, the 
sequencer plugin, or whatever sits in between the control surfaces 
and the DSP plugins. The DSP plugins cannot know what to do with this 
information anyway.


> or b)
> Adding some kind of 'gesture ID' field to events generally (so
> after you get a 'start-gesture 4578' all the events that belong to
> gesture 4578 are tagged as such in the event record)?

I just don't see the point. What do you want to do with that 
information anyway?

"Oh, now I'm getting two different streams of events for the same 
control. WTF am I supposed to do with them!?" :-)

Now, if you got the two streams on different inputs, you might have a 
clue as to which is which, and how to select or combine - but then 
you don't need any gesture IDs or sender information, as the data is 
qualified by which input it's sent to.


> Maybe
> there's another solution too, but mainly I'm just asking: Isn't
> there a problem here?

I think the problem is some confusion as to what's done where, and 
why.

Gestures as in "knob grabbed; <lots of data>; knob released;" are 
useless to normal DSP plugins. Only the host/sequencer can do 
something useful with this information. Just keep in mind that both 
custom GUIs and sequencers might be plugins using the same API as DSP 
plugins, so we can't ignore this stuff entirely.

Gestures as in "{ <events that belong together> }" are not needed, 
IMO, provided we require that timestamps and only timestamps qualify 
how control events are handled, eliminating event ordering from the 
equation. That is, events with the same timestamp belong together, 
and should be handled as if they were processed at the exact same 
time.


//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: