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

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

Other related posts: