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

Great analysis, Tim. Thanks.

I worry (probably too much) about making assumptions that pre-empt functionality. I can imagine situations where you might well want to have more than one sender per control, and I can imagine plugs that have their own internal sub-sequencing functions. Both of these wouldn't be possible with the solution you describe, yes? What if we add per-parameter properties (communicated to the host at instantiation time, etc.) for kWantsGestureEvents and kOnlyOneEventSource? (I guess the better, general form of the second would look more like thePlug->getControlMaxEventSourceCount( theControl ) -- so a plug can say 2 or 3 sources are OK, but it doesn't want to have to handle an unbounded number of them.)

Better or worse?

-- Chris G.


P.S. Happy New Year to all tonight!


On Tue, Dec 30, 2003 at 02:13:08PM -0800, Chris Grigg wrote: 
 Please forgive a question about one thing I don't understand about
 the concept of plugs being 'gesture-aware'.


I don't think plugs have any need to be gesture aware, outside of plugs that
host other plugs.

 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.  Won't this blow the plug's
 gesture processing out of the water?


Yes.  This is the host's job.  Two sources MUST have some relative priority.
For example, live MIDI data is more important than sequenced data.  The host
must be able to see that both the MIDI source and the automation source are
sending events at the same time.  They can either fight (yuck) or one wins.
If the prio is well understood, then it's obvious what happens.  The host
drops events from the automation source while the MIDI source is active.

The plugin that is being fought over does  not need to know ANYTHING AT ALL
about gestures or multiple sources.

Which leads me to my current thinking on gestures:


The host is what cares about gestures, so it can undo them.  That is the
primary use of gestures.  Touch automation is just a fancy undo, as I
understand.

It must be possible to include multiple controls in a gesture.

Anything that sends event can send gestures, but does not have to.


The way I see it working is best illustrated by an example:

* Assume a GUI controlling a DSP's parameters X and Y
* The GUI sends a GESTURE_START event to X and to Y
* The GUI can send any events it wants to X and Y
* The GUI sends a GETSURE_STOP event to X and Y
* The host knows all the events in that gesture, and can undo them
  atomically.

Now let's get fancy:

* Assume a GUI controlling a DSP's parameters X and Y
* Assume an automation engine sending data to X and/or Y
* The GUI sends a GESTURE_START event to X and to Y
* The host knows that X and Y have two sources.  It knows that GUI is higher
  priority than automation.  The host stops sending automation data to X
  and Y.
* The GUI can send any events it wants to X and Y
* The GUI sends a GETSURE_STOP event to X and Y
* The host can decide if it should resume automation or not - that is a host
  issue.

The main point to observe is that the GESTURE_* events are not really useful
to the plugin, but they are useful for the host.

Does that model seem to work?

Sorry for the deluge of email tonight, I have been thinking on this problem
for a while, and I *think* this is right.

Tim

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



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