[gmpi] Re: 3.11 Parameters
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Thu, 1 Apr 2004 18:11:03 -0800
On Thu, Apr 01, 2004 at 12:58:51AM +0200, Koen Tanghe wrote:
> > On Tue, Mar 30, 2004 at 08:13:10 -0700, Mike Berry wrote:
> >> - Can we have a way for a parameter to reveal its linkages to other
> >> parameters? I.e., if the host changes parameter 2, parameters 4 and 5
> >> may change?
> >
> > Do you have a use case for this? How will the changes be communicated back
> > to the host, and how does it play with automation?
> 1. external controller sends control change request to plugin (user tweaks
> GUI, moves fader, ...)
> 2. plugin handles the request and changes internal states
> 3. plugin in some way lets the external controller know what it did with the
> requested control value change (GUI feedback, motorized faders, force
> feedback, whatever, ...) and potentially also other parameters that depend
> the one for which a change was requested
> For example: control value change request --> plugin changes the associated
> parameter, but also other depending parameters --> external controller needs
> to be notified of all state changes that are reflected in the controller.
If we do proper MVC modelling (which we may or may not want to do :) then it
pretty much HAS to be bi-directional. We've talked about listeners, and I
don't think anyone balked on that. So if changing paramX means that you
change paramY, the listeners for X and Y would be notified. This means
potentially a lot of function calls per event...
Some of the function callbacks can be eliminated by assuming that any value
that is in-bounds will be accepted AS-IS by the plugin. That is, if I set
paramX (which is 0-200 range) to 123, the value will ALWAYS be set to 123.
Under no conditions will the plugin say "you sent 123, but I changed it to
100". The plugin might do things internally based on other parameters,
butthe exposed parameter would never be rejected while in-bounds.
The example given was a filter. When the cutoff is low, the resonance gets
lowered. I might set the resonance knob to 100% and then set the cutoff to
40 Hz. The internal resonance would change, but the parameter does not
reflect that.
This means that GUI plugins do not have to be registered listeners of the
parameters they control. Yes, it breaks strict MVC, but it means that the
majority of parameter changes (which pass through the GUI) do not involve a
function call from the DSP.
> Now, what if in "scenario a" the dsp part of the plugin decides that the
> parameter change it is receiving needs a change in another dsp parameter
> (observable at the outside at any of the attached UI's) depending on that
If you buy the above, then it can change the parameter internally, but it
can not change the external representation.
If it is a requirement that it be observable at the GUI (which is what I
need to be convinced of), then every GUI that controls a parameter needs to
be a listener of that parameter. The other dsp parameter that gets changed
by the dsp plugin would notify it's listeners. Which is what you said. :)
But is it really necessary that it be visible? Or maybe I'm optimizing
prematurely and doing proper MVC (which would involve the DSP [model]
notifying the GUI [view]).
> Now, the user presses a slider, or uses a MIDI control, or ... to set the
> min value to 0.9.
> This should not be allowed, since that would make it higher than 0.8 ! So,
> now you can do two things:
> - clip the requested parameter value to a valid value: 0.8 (which is the
> highest it can get)
> - ignore the request to change the parameter
> In both cases, you need to signal the UI (or ...) that another (or no) value
> was used than the one you requested, so that this external control can
> reflect the new current value.
Third case is to clip it internally and let the UI be wrong. It doesn't
sound so attractive in this case as in the filter case. This could be a
special case where the GUI is a listener.
set max to 0.8
-> GUI sets knob to 0.8
-> DSP is happy with 0.8
-> DSP notifies GUI that max is 0.8
-> GUI does nothing (wasted function call)
set min to 0.5
-> GUI sets knob to 0.5
-> DSP is happy with 0.5
-> DSP notifies GUI that min is 0.5
-> GUI does nothing (wasted function call)
set min to 0.9
-> GUI sets knob to 0.9
-> DSP is unhappy with 0.9
-> DSP sets min to 0.8
-> DSP notifies GUI that min is 0.8
-> GUI sets knob to 0.8 (useful function call!)
The vast majority of cases, the notification function call is wasted. So if
you assume that any in-bound value is legit, that vast majority does not
need the notification. For those weird cases (and KTGranulator is a weird
plugin :) the notification would be established and everything works.
> (B) the slightly more complicated case
Let's see if the hybrid I just dreamed up fits...
> Same as when we started with (A), but now, lock = true.
> Request to set min to 0.2
> This is OK, since that would require max to be 0.9 which is fine.
> --> Set min to 0.2 and set max to 0.9 and signal both changes to the
> controller (whatever that might be...)
> Request to set min. to 0.5.
> This is not OK, because that would require max to be1.2 which is illegal !
> So, again, we need to do something: either we ignore the request, or we
> change min to the maximum allowed value, which is 0.3 (depends on max!) and
> set max to 1.0.
> --> controller should be notified of this so it can reflect the changes
assume max is 0.8 and min is 0.1 (if I interpret correctly)
set lock to TRUE
-> GUI sets button to TRUE
set min to 0.2
-> GUI sets knob to 0.2
-> DSP is happy with 0.2
-> DSP notifies GUI that min is 0.2
-> GUI does nothing (wasted function call)
-> DSP sets max to 0.9
-> DSP notifies GUI that max is 0.9
-> GUI sets knob to 0.9
set min to 0.5
-> GUI sets knob to 0.5
-> DSP is unhappy with 0.5
-> DSP sets knob to 0.3
-> DSP notifies GUI that min is 0.3
-> GUI sets knob to 0.3
-> DSP sets max to 1.0
-> DSP notifies GUI that max is 1.0
-> GUI sets knob to 1.0
> I'm not sure that specifying all the possible ways in which parameters can
> be linked should be done, but a way to have some bidirectional communication
> about parameter dependencies (or "linking") is something I have needed in my
> simple plugin.
Your plugin is not so "simple" :)
Does this seem to work?
----------------------------------------------------------------------
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:
