[gmpi] Re: 3.11 mini-wrap: Dynamic params/multi-timbral

Sorry to nitpick, but since we're getting all nitty-gritty about param addressing I think we need to be careful now.

Point being: Even if you were going to do it in pure OSC addressing syntax, wouldn't the example be just 'channel0/shape'? Or '0/shape'? Syntax says [containerName/] [.../containerName...] methodName, and channel 0 is the only container there. 'osc' is more like the namespace that channel0 is drawing its parameters from, analogous to the per-slot parameter name lists I described earlier. And channel 0 is the container in the model we've been describing, whereas channel/0/ describes a container called channel with a subcontainer called 0, which is different.

Just wanna make sure we're looking at apples vs. apples as we make our decisions about what we like.

-- Chris G.



Hi Tim,
Looking good...noticed this bit...

"/channel[0]/osc/shape"

could we do it like OSC?...

"/channel/0/osc/shape"

(square brackets are reserved in OSC)

Just a thought,

Jeff




 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: http://www.freelists.org/archives/gmpi
 Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe"
 to unsubscribe



----------------------------------------------------------------------
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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe



----------------------------------------------------------------------
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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: