[gmpi] Re: Topic 8: Parameters
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sun, 10 Aug 2003 15:40:11 -0700 (PDT)
> > 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)?
It depends. If the range used to be 0 to 10, and is now 0 to 5, the
semantics of the control MAY be different enough to warrant a change. You
see, in this case, the range narrowed. Some old data is no longer valid.
That is not to say that the plugin can't handle out-of-band data by
clamping to the min/max.
> 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).
This control remains EXACT semantic compatibility with old data. Any old
data is valid. The range was widened.
> >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.
I wrote that as a response to one of the examples that was asked. Someone
(Marc?) asked about compatibility for a control whose range changed, but I
think he meant more generically 'semantics changed'.
In this case, I'd say no, don't make a new control, because the old one
still works.
> 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.
If controls are normalized, there is never a data-validity issue, but there
is a data-meaning issue. If natiral ranges are used, there is never a
data-meaning issue (unless you change the units) but there is a
data-validity issue.
In all cases, we need rules for how to handle out-of-range data. If your
control goes from 0 to 10, and host gives you 11...
Does the plugin handle it and clamp internally, so senders don't worry?
Does the sender have to clamp it, so the plugin can just assume validity?
Tim
> 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
>
----------------------------------------------------------------------
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:
