[gmpi] Re: wrap up 3.8 - gesture start/end
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sat, 10 Jan 2004 01:58:06 +0100
On Friday 09 January 2004 15.10, RonKuper@xxxxxxxxxxxx wrote:
> (***) 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.
>
> <<<
>
> Sorry for the long absence. Combination of holidays, a death in
> the family, and email problems here at Cakewalk.
>
> Please read up on what DirectX automation does for parameter
> capture/release. (That's the terminology used there,
> capture/release like a mouse, rather than gestures which can easily
> be confused with musical performance gestures.)
I vote for borrowing that terminology. It makes sense, whether we're
talking about GUI widgets, physical controllers or weird event
processors that might want to (ab)use the feature.
> In DX8 the host optionally exposes a parameter capture/release
> interface. If the plugin wants to use it, I can query for it.
> Then, then the user clicks on a widget in the plugins GUI for
> parameter foo, the plugin says host->ParamCapture( foo, TRUE ).
> Then as the widget moves, host->ParamChange( foo, x ), the finally
> host->ParamCapture( foo, FALSE )
>
> This approach is neither 1 or 2, and actually works pretty well.
What you describe sounds to me *exactly* like what we've been
discussing, except that it appears to be using function calls rather
than events. (And no IDs, but that's additional information, and
doesn't really change the logic behind the capture/release feature.)
As to the paragraph with the two options above, it's about what hosts
can do with the information, rather than about the feature itself, as
I understand it. I'm quite sure DX hosts could implement dumb merging
(1) or priority switching (2) between data from DX plugin GUIs and
the automation sequencer, and that's what this stuff is all about.
(And maybe keeping related controls together, which is why we got
into IDs and stuff.)
//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: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
