[gmpi] Re: Summary: 7.3

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Thu, 7 Aug 2003 12:04:46 -0700 (PDT)

> 8.    Parameter representation
> What data type for values, for names?  How do we support validation, 
> value distribution?  Are parameters presented as a flat list or in some 
> hierarchy?

Killer!  Thanks.

> So lets split it up:

Can I insert one?

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.

* Saving and restoring a full set of parameters is sufficient to resotre the
  state of a plugin 'patch'.

* Parameters must be independant of each other.

* Parameters can change in real-time.

> 8a.) What value types can be used for parameters?

Obviously some numerical type is needed.  Simplest is to say all parameters
are floating point.  But this violates the idea that GMPI works on FPU-less
systems.  Maybe all numerical parameters are the same type as an audio
sample?  I think string parameters are also needed, for things like
filenames, text-to-speech, etc.  In XAP, we had int, float, string, enum,
and raw, with simple wrappers to make an int or enum (I forget) taste like 
a bool.

Int/float can possibly be consolidated.  In LADSPA, everything is float, and
it seems OK.  You can map int onto float by a simple hint that only whole
numbers are meaningful.  Conversely, if we do complex time stuff, floating
point may become required, and not just FP, but double precision FP.  Single
precision can drift a LOT with tiny values.

Enum was built on int, but provided value names and a fixed set of values.
Think of something like a 4-position knob.

A bool can be a 2-position Enum.  Think of a switch.

Raw was for unforseen stuff.  A way to read out some internal state from a
plugin and later restore it.

> 8b.) How are parameters identified? By index? By string? By unique ID?

This doesn't really matter right now does it?  A parameter has some unique
path within a plugin, and that alone is sufficient.  It may be a
plugin-global string or integer or index.  Doesn't matter, yet.

> 8c.) How are properties of a parameter enumerated by the plugin, 
> including (only if necessary) type, range, identifier.

Again XAP:  I had suggested a base XAP_control, which had some fields:

struct XAP_control {
        XAP_ctrl_type type;     /* the type of control */
        const char *label;      /* plugin-unique label */
        const char *name;       /* display-friendly name */
        const char *hints;      /* hints to the host */
        uint32_t flags;         /* global and per-type flags */
        uint32_t rtflags;       /* realtime flags */
};

Each type-specific control extended this:

/* int controls have a min, max, and default value */
struct XAP_ctrl_int {
        struct XAP_control base;
        int min;
        int max;
        int default;
};

/* float controls have a min, max, and default value */
struct XAP_ctrl_float {
        struct XAP_control base;
        float min;
        float max;
        float default;
};

/* enum controls have a min, max, and default value and names for each value */
struct XAP_ctrl_enum {
        struct XAP_control base;
        int min;
        int max;
        int default;
        const char **options;
};

/* strings just have a default */
struct XAP_ctrl_string {
        struct XAP_control base;
        const char *default;
};

struct XAP_raw_data {
        int size;  /* bytes */
        void *data;
};

/* raw just has a default */
struct XAP_ctrl_raw {
        struct XAP_control base;
        XAP_raw_data *default;
};


I need to insert a topic.

8c.1) Are controls normalized or not?

This is a can of worms.  Arguments for it.  Arguments against it.

> 8d.) Is there a heirarchy of parameters?

Not clear what you mean?  I definitely see a need for sub-units within a
plugin, in which parameters exist.

> 8e.) Can the parameter list change dynamically?

I envisioned something where you can add/remove sub-units dynamically, and
each sub-unit has a static list of parameters. So yes, in a way.  Think of
mixer slots.  You can dynamically add a mono mixer slot.  It has parameters
for volume, pan, maybe some EQ params.  Every mono mixer slot has the same
parameters, but you can have n mixer slots.  And to make it more fun, stereo
mixer slots might have a different list of parameters from mono.

> 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?

Not clear - do you mean automatable vs. not?  or do you mean realtime vs
not?

I also see a use for something I've dubbed an 'argument'.  An Argument is
something passed to the plugin at creation time - for example, a wrapper
plugin would have an argument of the plugin to wrap.  Those would be
unchangeable.

If you can take the view that EVERYTHING (except arguments) is a parameter
(or 'control' in XAP), then sequencing becomes a case of automation playback.

MIDI note-on becomes a change in the NOTE parameter.  Aftertouch becomes a
stream of changes to the AFTERTOUCH parameter. Filter sweeps become a stream
of changes to the CUTOFF parameter.  Tempo changes become a change to the
TEMPO control.  If a plugin doesn't have a tempo param, it must not care
about the host tempo.  If a plugin has a NOTE param, it can be played by the
sequencer.

It's pretty different than anything that I've seen out there, but it seems
to be pretty elegant.



I think we should let the topics bubble up for a day or two, then start
again with one topic at a time.  Otherwise the noise gets hard to follow.

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: