[gmpi] Re: lost-n-found #3 parameter stuff

On Saturday, November 06, 2004 1:09 AM [GMT+1=CET],
Tim Hockin <xxxthockin@xxxxxxxxxxxxx> wrote:

> You're making 2 arguments.  You asked about one parameter affecting how
> another parameter works - you use a pre-processor for that.

Yeah, well that was not the important part I guess, so I should just have
said that it's always in cents or semi-tones no matter what. Pre-processors
can be used for that indeed.

Could you please still spell out the steps involved in the case I described,
if you still feel like it or have the time? I think I need to see it to be
completely reassured ;-)
- spin control in host UI for frequency displayed in Hz with single
- "up arrow" click
- step either in semi-tones or in Hz according to second parameter

> Then you asked about increment/decrement.  As I said in a separate email,
> I'm not heavily vested in a position on that.  If it's really useful, then
> fine.  I'm not convinced it is, but a few other of you seem to be, so OK.

Well, initially I didn't think of that myself, but given Mike's explanation,
I think it makes sense.

> So just to be clear:
> - I am fine with parameter->to_string conversions (optional per param?)
>   eg: char *str = param->to_string(value);
> - I am fine with parameter->increment method (optional per param)
>   eg: newval = param->increment(oldval, n);
> - I am not convinced that parameter->from_string is really that useful,
>   but could be convinced.
>
> All of these are complexity.  If we make them optional, then hosts have to
> test for them and have default handling.  If we make them mandatory, then
> plugins will all have to provide them and have that bloat.

Since not everybody thinks it will need to be more than just a "atof", why
not just provide default implementations that do just that and let the
plugin override them somehow if it wants to?
    from_string : atof
    to_string : snprintf
    increment_method : +n
Those who don't care just don't care and leave it that way. Those who do
override the calls (somehow, don't want to enter into specs now, so we don't
know if it's gonna be virtual methods or anything else).

> The fact that VST has this makes a strong case, if only for compat.  The
> fact that no one uses it makes me worry.

Supposing "this" and "it" are about VST's string2parameter, I'm not sure no
one uses it. I just asked on the VST mailing list (both plugin devs and host
devs) and will let you know what comes back...
The only thing I know is that getParameterProperties is not required
according to the docs. string2parameter IS in the "basic set of methods that
your plug should support" though, just like getParameterDisplay, and it is
implemented in the base class as returning false by default...

Need to catch some sleep now.

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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: