[gmpi] Re: 3.11 mini-wrap: Dynamic params/multi-timbral
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: GMPI list <gmpi@xxxxxxxxxxxxx>
- Date: Thu, 29 Apr 2004 00:05:23 -0700
Ok, here are the reqs that I have gathered so far for the topics of
Dynamic Plugin Structure and Multi-Timbral Plugins. Please comment, let
me know if these work.
-------------
* GMPI must support dynamic parameter lists. When the parameter list
changes, the host must be notified by the plugin. Hosts must be able to
deny a parameter list change.
More on this requirement:
During discussion with the GMPI working group, dynamic plugin structures
was determined to be an elegant solution to a number of specific use
cases. Thise use cases are included here.
1. Semi-modular plugin
A synth has 4 oscillators, each of which may be one of three types,
each with different parameter lists. The synth has 2 filters, each of
which may be one of two types, each with different parameter lists. It
has 2 effects, each of which may be one of 6 type, each with different
parameter lists. It also has a long list of global parameters. See
Linplug Albino for an example of such a beast. The resulting parameter
list has all the parameters for all the modules. The custom UI can
show only the relevant params, but the parameter list shows ALL the
params.
Identifying which params are relevant in the list of all params is
difficult. Ideally, there would be a way to mark parameters that are
currently relevant.
2. Modular plugin
A modular environment has dozens of loadable modules, each of which has
a unique parameter list. Each module may be loaded any number of
times.
The list of parameters is truly dynamic. All parameters should be
automatable. Ideally, the list of audio inputs and outputs would be
dynamic, too.
3. Multi-mode plugins
A reverb can handle mono, stereo, or 5.1 inputs. Ideally, one plugin
will work for all these IO types, dynamically.
4. Multi-stream plugins
A compressor could affect any number of parallel streams based on a
single master input. One plugin should be able to handle 1, 2, or 100
mono inputs, dynamically.
-------------
(something similar needs to be said about IOs)
-------------
* There must be a way for GMPI plugins to save and restore their
parameter-list structure with a patch.
More on this requirement:
During discussions with the GMPI working group, there were several
alternatives proposed for how a plugin can store its structure with a
patch. There might be a 'state header' which is saved/restored before the
parameters. There might be a notion of 'properties' separate from
'parameters' (as in AU) which are saved/restored before parameters. There
might just be an opaque parameter which holds this information.
All of these methods could work.
-------------
-------------
* GMPI must support grouping of associated parameters. Grouping may be
arbitrarily deeply nested.
-------------
-------------
* GMPI must support multi-channel plugins. Each channel may have any
number of parameters and/or IOs. There may be an arbitrary number of
channels per plugin. It must be possible for a host to save a just a
single channel's patch as well as the entire state of a plugin.
More on this:
The GMPI working group proposed several viable ways to handle groups and
multi-timbrality. The simplest use case for this is a GM-compatible
plugin. A brief overview of some of the methods that were proposed is
included here for completeness.
1. OSC-like naming
If the parameter list is truly dynamic, then grouping and channel layout
can be encoded into the parameter name. If we codify a slash (/) as a
delimiter, then each parameter can be viewed as a path through a tree.
Leaf nodes on the tree are parameters, and non-leaf nodes are groups. For
example, if you have the following parameter list:
"/volume"
"/osc/shape"
"/osc/octave"
"/filter/cutoff"
"/filter/resonance"
You can assume that there are two groups, "osc" and "filter", each with
two parameters, as well as a single top-level parameter, "volume".
If you define a set of well known top-level nodes to represent things like
channel grouping, you can turn the above example into something like:
"/master/volume"
"/channel[0]/osc/shape"
"/channel[0]/osc/octave"
"/channel[0]/filter/cutoff"
"/channel[0]/filter/resonance"
This clearly defines the plugin as having one channel, with a clearly
defined channel structure. Plugins which want to be multi-timbral can
have multiple indices in the /channel[] array. In fact, channels can even
have different structures.
2. Slots or Modules
Instead of assuming the parameter list is an array of parameters, it can
be considered an array of channels, each of which has an array of
parameters. This allows a plugin to internally define common structures
once, and saves the need for gratuitous string copying. It allows for an
arbitrary number of channels, each of which may have an identical or a
different structure. This combined with the slash-delimited names also
provides arbitrary grouping.
-------------
----------------------------------------------------------------------
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:
