[gmpi] Re: 3.11 topic: Inter-parameter linkages
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Mon, 5 Apr 2004 17:01:35 -0700
On Mon, Apr 05, 2004 at 05:29:16PM -0600, Mike Berry wrote:
> 1.) Parameter changes in the plugin's custom UI (this is what it was
> designed for, I believe).
>
> 2.) Parameter linkages, where we call setParameter on one parameter and
> we get back a setParameterAutomated call for another parameter.
>
> 3.) Potentially, this method could be called at any time during process
> (there are no rules stated) but I have not seen this yet.
> 2 has caused innumerable headaches for us. Because parameter changes
> are often undoable, we cannot offer single parameter undo, because
> multiple parameters may change.
OK, I can see the undo problem. We've talked about gestures being the
atomic undo unit. If a parameter is changed as part of a gesture, it is
undoable. Maybe we can make an parameter which changes spontaneously (or
rather which is changed by the plugin itself) inherit the gesture from the
source.
Example:
start gesture G for param A
set A to V1
internally start gesture G for param B
internally set B to V2
end gesture G
Does that seem to fly?
> Non-uniform linkages have also been a problem. Take 2 parameters, A
> and B. When you change A it changes B, but when you change B, it does not
> change A. Now imagine automation recorded for A, then B. When you play
> back with automation, a little war occurs between the recorded
> automation for B and the implied values due to the linkage to A.
That "little war" is inevitable sometimes. If you have two controllers
trying to alter the same model (back to MVC terms) you *do* have a conflict.
There needs to be well-defined rules for resolution of that conflict. We
talked some about this when we talked about gestures..
> So I guess to sum up, I would suggest making all RT parameter
> linkages inside plugins illegal. This does answer the question of whether
> or not plugins need to enumerate parameter linkages :)
There were two use cases that were brought up for internally generated
events:
* Min and max knobs which are offset and lock in step. Increasing min
increases max. Max can not go above the maximum value for that param.
min can not go below the minimum value for that param.
I can see how these COULD be defined as a single complex parameter. It
makes what are otherwise simple knobs pretty difficult.
* Patch morphing. Based on some input, the plugin morphs over time from one
patch to another. These morphs should be visible in the GUI.
You can't make ALL the parameters be one big parameter. ??
----------------------------------------------------------------------
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:
