[gmpi] Re: Topic 8: Parameters
- From: "Koen Tanghe" <koen@xxxxxxxxxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Sun, 10 Aug 2003 23:21:36 +0200
----- Original Message -----
From: "Tim Hockin" <thockin@xxxxxxxxxx>
> > > 1) range change
> > > - make a new control** with the new range and a new name
> >
> > I personally don't like the idea that changing a parameter's range (or
> > another property) of a parameter would require you to make a new
parameter
> > with a new name! That just doesn't feel right at all to me. It IS still
the
> > same parameter, only some properties have changed, but it still has the
same
>
> If a control is semantically compatible with an old version, then there is
> no reason to change it's name.
> If it is not compatible, well, then it
> really IS a different control, no?
Well, do you consider a range change something that breaks semantic
compatibility (I don't)?
Let's say you have a simple filter with one of it's parameters the filter
type.
In the first version of your plugin you have three possible filter types
(low pass, band pass and high pass). Now, in a next version of your plugin
you are now also supporting 3 extra filter types (notch, low shelving, high
shelving).
Or consider something similar with the range of possible delay times for a
delay plugin.
From what you wrote above, I understand that you consider a range change as
a reason to make a new control with a different name.
And I wanted to say that this really doesn't seem like a good idea: the
control still has exactly the same semantic meaning, only the range has
changed, and to me it is definitely not a different control.
And Marc wrote:
> However, here's one thing to think of:
> if we agree to use literal parameter ranges/values (i.e. not normalized
> ranges, but specific min and max for each parameter, which I really really
> really really hope that we do, then changing the range of a parameter
> won't cause any compatibility issues, and therefore won't require a new
> parameter in Tim's scheme, or any sort of translation at all.
OK, I see.
But for me, even IF the parameters would be represented using 0-1 range, a
change of range (in the natural domain of the parameter) should not involve
changing a parameter's *name*. Of course, the meaning of 0.2 for a parameter
will change if the range changes, but the *name* should be exactly the same,
and the plugin should deal with the interpretation of the 0-1 ranged value
based on the version number of the parameter settings.
Now, using the natural domain of the parameters instead of the 0-1 range
eliminates the need for handling this "artificially".
I do wonder if this could have any important implications for hosts when
dealing with parameter automation. I guess it's pretty generic if all
parameters are just floats in a 0-1 range, as opposed to dealing with
different parameter types in non-normalized ranges. Although again, the
latter would seem the most natural way to do it.
Koen
----------------------------------------------------------------------
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:
