[gmpi] Re: Topic 8: Parameters
- From: "Silver Blade" <lists@xxxxxxxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Thu, 7 Aug 2003 23:19:26 +0100
> 8a.) What value types can be used for parameters?
I'd say float/double, but using values appropriate to the plugin. So, the
range wouldn't be -1.0 to +1.0, but some value range meaningful to plugins.
This would be useful for things like waveform selection, where currently
plugins have to work out what waveform is selected by converting 0.0 to
sine, 0.3333r to sawtooth, etc. Instead, it could just be 1 2 3 4 ...
True, an integer would be sufficient for that, but a float or double means
almost any type of value can be represented.
> 8b.) How are parameters identified? By index? By string? By unique ID?
By index. Quick and easy. We can then expand on this later if necessary. As
long as parameters can be queried by index, additional information can be
added such as string representation.
> 8c.) How are properties of a parameter enumerated by the plugin,
> including (only if necessary) type, range, identifier.
The clean way would be to have the host call the plugin repeatedly to
enquire about each parameter.
The fast way (which is probably overkill for this) would be to have the
plugins maintain an array of parameters and information about them, and
return the entire array upon request. This could have a global scope so
there wouldn't be any chance of memory leaks (ie, allocate memory in a
routine, return structure, never freed...)
However, in this case, clean way would be simple and easy to understand.
> 8d.) Is there a heirarchy of parameters?
Not entirely sure what this means. A "tree"? So you can have reverb with
type, size, etc. branching off of it? It'd be a good idea, although I think
it'd be best utilized by hosts to simply group common parameters, and allow
the user to hide a section of parameters he or she is not interested in
seeing.
> 8e.) Can the parameter list change dynamically?
Yes. Different values for other parameters might cause other parameters to
become available or unavailable. This might be rare, but there is no point
in showing controls which can't be used, unless the plugin's GUI (if it has
one) requires all controls to be visible.
> 8f.) Is there a distinction between a time-varying parameter and a
> non-time-varying parameter? Is this a fixed characteristic, or can it be
> changed?
Is this about automation? In any case, I'm not sure. It'd be good if
parameters could be marked as automated and non-automated, in case that
matters to hosts/plugins. Well-coded plugins could use this information to
determine when various calculations should be performed, perhaps? I think
others would be better to comment on this.
-Andrew
----------------------------------------------------------------------
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:
