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

Hi Chris,

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

I understand that the host will mediate all parameter changes. So if for
example pre-recorded automation is moving a fader, and the user starts
moving that same fader, the host will decide which gets priority.

  So the answer is option A) "Adding a host-side target exclusivity/locking
mechanism to avoid interference with the gesture processing"

>I don't understand about
> the concept of plugs being 'gesture-aware'.

   It's a good question, if the host is handling the gesture, why does the
plugin need to know about gestures?

  I think the answer is: Most plugins won't need gesture info, but for
completeness, it's nice if the plugin has the option (perhaps the plugin is
a wrapper and needs the gesture info), or the plugin itself is some kind of
sequencer and needs to record/send gestures.

( as usual, this is my understanding of things, I may be wrong).

Best Regards,
Jeff

----- Original Message ----- 
From: "Chris Grigg" <gmpi-public@xxxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Wednesday, December 31, 2003 11:13 AM
Subject: [gmpi] Re: Reqs 3.8 Events - gesture start/end


> 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.  Won't this blow the plug's
> gesture processing out of the water?
>
> 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, 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)?  Maybe there's another
> solution too, but mainly I'm just asking: Isn't there a problem here?
>
> -- Chris G.
>
> ----------------------------------------------------------------------
> 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: