[gmpi] Re: wrap up 3.8 - gesture start/end
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 6 Jan 2004 15:21:21 -0800
A potential wrap-up for gestures? How does this sound? I'll work it into
the requirements, if it is OK with everyone.
* GMPI must support grouping events into 'gestures' (*).
* It must be possible to include multiple events for multiple controls in a
gesture (**).
* Anything that sends events can send gestures, but does not have to.
* The host must handle the case of overlapping gestures for one control (***).
(*) Gestures are a logical grouping of a series of events. If events are
explicitly joined by gestures, then they may be handled atomically. Hosts
might use this for undo functionality, touch automation, or other features.
Plugins do not need to do anything for gestures. It is expected that most
plugins will not be gesture-aware themselves.
(**) As an example model, consider the case of a GUI plugin (or a
touch-sensitive MIDI controller, or similar) controlling a DSP plugin.
* When the user clicks the GUI (or touches a control), the controlling
plugin sends a gesture-start event with a unique (host-provided) ID to
the DSP parameter being controlled.
* The host and/or plugin recognizes the gesture has started.
* Subsequent events include the gesture ID, so the host and/or the plugin
can group them.
The gesture ID is needed in the case of multiple DSP parameters in a single
gesture. The above process would be done with the same gesture ID on each
parameter. The actual implementation details will be decided during the
specification and implementation. The above is simply to clarify the idea.
(***) Any host which allow multiple event sources for one target needs to
handle overlapping or simultaneous inputs. There are a couple viable
options:
1) Do nothing. Send all events to the plugin. The vast majority of plugins
do not care about gesture-start and gesture-end, and will ignore them. If
two sources fight, you will get a knob that jumps around. Plugins don't
need to handle anything special, and ignore things they don't need.
2) Act as a priority-based switch. Based on the source of inputs, decide
which events make it to the plugin, and which get dropped. Plugins don't
need to handle anything special, and ignore things they don't need.
Both solutions are perfectly acceptable, and are NOT mutually exclusive.
----------------------------------------------------------------------
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:
