[gmpi] Re: Decision time: 8.2

--- Paul Davis wrote:
> >Okay, I'm starting to think that maybe I just don't know what issue
> >you're talking about on a more basic level.  I've just been saying that

> >there needs to be a way to mark the beginning and end of parameter 
> >gestures in a general way, so that anyone can produce those 
> >notifications:  host, GUI, DSP plugin, whatever.  You seem to agree. 
So 
> >why was this even an issue to begin with?  I can't figure out anymore
at 
> >this point...
> 
> let me try :)
> 
> scenario a: 
> 
>   user clicks on an on-screen slider and moves it. the GUI controlling
>   the slider finds out about this, and sends a parameter change
>   request to the host: "set parameter N of plugin XXXX to YYY.ZZZZ".
>   host sends parameter change to plugin, which will probably
>   interpolate and/or remap it internally.
> 
> scenario b:
> 
>   as above, except that the host is doing automation, so ...
>   when the change to parameter N arrives, it notes the time and
>   stores the value someplace.
> 
> scenario c:
> 
>   as above, except that the host does undo as well, so ..
>   when the "first change" to parameter N arrives (with "first"
>   defined by the host, presumably based on recent activity),
>   it stores it as the "undo" value.
> 
> scenario d:
>  
>   as any of the above, but the host also supports touch automation,
>   so the GUI also calls a "startParameterChange"
> method/callback/whatever
>   in the host when the mouse button down event arrives, and an
>   "endParameterChange" method whenever the mouse button up event
>   arrives.
> 
> in every case, the DSP plugin is not involved in any way.


Okay, I looked back in the archives and found the original statement (from
Mike Berry) that started this debate:


I agree that the UI is separate, but I still think that we want a way for
the plugin to tell the host two different pieces of information:

- a parameter has changed due to something that the host does not know
about.

- plugin-based parameter changes for a particular parameter are finished.


And then Steve Harris disagreed with that, and then I disagreed with Steve
and agreed with Mike.  So I guess then that the point of disagreement here
is whether or not the DSP component should have a way to mark beginning
and ending of parameter gestures.  And you and Steve are saying "no."  I
am still saying "yes."

scenario e:

    The DSP component of the plugin wants to mark a parameter 
    gesture, for whatever reason it may have, it wants to and 
    should be able to.

Why is there opposition to this?  Why not just let anyone generate these
begin/end notifications?  Why exclude the plugin itself?

Here's a real world example, and I know of plugin makers who do this, so
already we can forcast problems with this arbitrary (so far as I can tell)
rule:

The plugin allows for MIDI CCs to control parameters.  And it allows for
the plugin to "broadcast" these parameter changes resulting from MIDI CCs
as automated parameter changes, so that they can be recorded as automation
data in a host app and thus reap the benefits of whatever automation
editing/handling capabilities that the host provides, which might be
preferable to dealing with MIDI data.  In order to be able to simulate
these parameter change gestures, the plugin uses a time-out system where
MIDI events falling within a certain time-span next to each other are
considered part of a single gesture.  So the first MIDI event to arrive
beyond the time-out duration after the previous event will mark the
beginning of a gesture, and any subsequent events that still fall near
enough to their previous events will stay in that gesture, until time-out
is reached and the gesture is marked as finished.  This is how a lot of
hardware surfaces handle control changes, too.  To accomplish this, the
DSP component of the plugin needs to be able to mark beginnings and
endings of parameter change gestures.  And there can be plenty of other
reasons why plugin may want to do this.  I really just don't understand
the opposition to this, why anyone would just want to make a rule against
this.  I don't see any good reason for that, whereas I do see reasons to
keep the possibility open.

Marc

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

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