[gmpi] Re: Reqs 3.8 Events - gesture start/end
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 31 Dec 2003 03:22:04 -0800
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: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
