[gmpi] Re: 3.11 Parameters
- From: "Koen Tanghe" <koen@xxxxxxxxxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Thu, 1 Apr 2004 00:58:51 +0200
On Wednesday, March 31, 2004 3:56 PM [GMT+1=CET],
Steve Harris <xxxS.W.Harris@xxxxxxxxxxxxxxxxxx> 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?
Aha!
I don't feel like explaining this all over again, so I'll just copy/paste it
here, because I think it might be relevant at this point:
----- Original Message -----
From: <RonKuper@xxxxxxxxxxxx>
> Other topics (and ultimately the specification) will hopefully cover
> issues about how parameters are represented, named, organized and
> discovered. This would be pretty elemental in a control surface
> integration system.
Might be more something to be saved for later on in this process...
The way I see it is that a GUI, hardware control surface, sensor, other
program, etc... are just external controllers that communicate with the
plugin through the control ports. BUT, I think it is also worth noting that
this communication should be bidirectional:
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.
---------------------------
and also:
----- Original Message -----
From: "Paul Davis"
> 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.
>
> <SNIP>
>
> in every case, the DSP plugin is not involved in any way.
Alright, I'll just jump in to this since the above "scenario a" does seem a
bit simplistic to me, and as practical examples tend to help out
sometimes...
I hope you guys don't mind ;-)
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
first parameter? I would think that in that case the dsp code itself should
have a way to tell the outside world (probably through the host) that
something has changed to that other parameter, right? How would you solve
this without allowing the dsp code to notify other listeners of parameter
changes?
Koen
PS
The way I am handling this in a VST plugin of mine, is by calling a
setParameter function of my dsp core code with an extra argument that can
be used to return other parameters that might have changed during the dsp
setParameter call:
setParameter(inParamIndex,inParamValue,&outListOfChangedParameters)
The code calling the dsp core (in my case the VST effect class around the
dsp core, called by the host) then checks the list (might be empty) of
returned parameters that have changed and uses getParameter on the dsp core
to obtain their eventual value and propagate this to the outside world (the
environment the plugin "lives in", probably the host).
This is a function-based scheme, but I guess it would be better and more
flexible to do this with a real listener/notifier design.
---------------------------------
And for a practical use case:
---------------------------------
For a whole set of "properties" in my KTGranulator, I have a minimum and a
maximum value that the user can set (minimum delay and maximum delay). Now,
if I change one of them (say the minimum) the values it can get will depend
on the value of the other (the maximum). And to make things worse: if the
two are locked, I want a change in one of them to cause a change in the
other.
So: 2 parameters "min" and "max" have values always between 0 and 1
(these are absolute min. and max. value boundaries) and a third one that
specifies locking between the two first (call this "lock").
Say the the current values are:
min = 0.1
max = 0.8
lock = false
(A) the simplest case
Now, the user presses a slider, or uses a MIDI control, or ... to set the
min value to 0.5.
That's OK, since 0.5 is still <= 0.8.
Now, the user presses a slider, or uses a MIDI control, or ... to set the
min value to 0.9.
This is signaled from the UI (or ...) to the engine class, so we get a
request to set min 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.
(B) the slightly more complicated case
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
---------------------------------
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.
A notification/listening model has also been proposed some time ago for
solving these things.
Koen Tanghe - Smartelectronix
----------------------------------------------------------------------
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:
