[gmpi] Re: 8a.0 What is a Parameter?
- From: Marc Poirier <fipnid@xxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Thu, 7 Aug 2003 13:34:08 -0700 (PDT)
> From Tim:
Just to start with, I *really* don't like a "facilitator" starting a topic
with answers, rather than just questions (particuarly answers for the
entire topic, and then saying that we should only deal with the first
sub-topic, yeesh). In the future, please consider this and not abuse your
role by trying to excert more power and domination over the process than
you should.
> 8a.0) Define "parameter".
>
> In XAP we called these 'controls'. My spin (off the top of my head):
>
> * A parameter is an explicity exported representation of some
variable(s)
> inside a plugin.
>
> * Parameters may represent things like knobs on hardware, plugs in a CV
> module, coefficients of algorithms, or more abstract values like
tempo or
> MIDI controllers.
>
> * The set of exported parameters are a snapshot of the current state of
> a
> plugin.
This all sounds like a fine definition to me.
> * Saving and restoring a full set of parameters is sufficient to resotre
the
> state of a plugin 'patch'.
>
> This can work if one of the parameter types is arbitrary data (this is a
> term that Premiere and AfterEffects use in their API's). Basically, in
> addition to the host-intelligible parameters, a plugin can have arb data
> parameters, which is basically an opaque chunk. VST has a variation on
> this with its getChunk and setChunk functions, but they are split off
> from being parameters,
Yes, this complete either/or split between the two state descriptions,
either entirely float parameters or entirely opaque data, has always been
a problem and nuisance in VST, I would rather avoid that. I also like the
idea of having arbitrary data parameters as an option when necessary,
mixed in with known data type parameters.
> * Parameters must be independant of each other.
>
> Is this necessary? I'm not sure that it is.
I think that these are both totally vague statements, and the discussion
of this point should begin with someone saying what inter-parameter
dependencies and a general concept of its implementation. If no one has
such desires, then I guess that means that parameters will be independent,
which may be fine. But I have a feeling that Koen might have more to say
about this... ;-)
> * Parameters can change in real-time.
I strongly object! Ummm, wait, I changed my mind, yeah, I don't think
this point will need any debating... ;)
Someone also mentioned something about parameter hierarchy. I'm not sure
if that's needed, but parameter groups (or "clumps" as we now as in
AU-land), are a great thing and I think that GMPI should at least do that.
So I'm suggesting not so much a full-blown hierarchy, but one level of
nesting. Parameters descriptions can indicate that a parameter is a
member of a clump by specifying a clump ID, and then the plugin can supply
a list of clump IDs with names for each clump. This allows for the
possibility of much better generic interfacing to the plugin (like
providing parameter list with well-organized sub-menus, arranging
parameters in logical groups in a generic GUI, etc.).
Marc
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
----------------------------------------------------------------------
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:
