[gmpi] Re: lost-n-found #3 parameter stuff
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 5 Nov 2004 16:09:51 -0800
On Fri, Nov 05, 2004 at 11:30:30PM +0100, Koen Tanghe wrote:
> >> Well, in case 1 I might want the frequency to step in cents or
> >> semi-tones if some other boolean parameter is switched on, so a default
> >> step of 1 will not do.
> >
> > Parameter Pre-processor. That is exactly what it is for.
>
> Just to make sure I can agree with this:
> - user presses "up" arrow on spin button in host UI
> - now the host needs to change the plugin parameter with some amount
> --> with what amount (depends on current value and other parameter value)?
> --> does the host just send a "+1" message and then the plugin decides what
> this +1 should be in reality?
> How would this be done with a pre-processor (sorry for being so stubborn,
> but I want to make sure these things will be possible).
You're making 2 arguments. You asked about one parameter affecting how
another parameter works - you use a pre-processor for that.
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.
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.
The fact that VST has this makes a strong case, if only for compat. The
fact that no one uses it makes me worry.
Tim
----------------------------------------------------------------------
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:
