[gmpi] Re: 3.11 topic: Dynamic plugin structure

On Wed, Apr 21, 2004 at 08:26:29AM +1200, Jeff McClintock wrote:
> True,  My main objection was a synth having different parameters sets on
> different patches.

I agree that this is not the nicest.  Let me ask this, though:

Assume we do get some sort of dynamic structure.  How do you encode the
dynamic structure into a preset/patch when we've so far talked about a
patch just being the set of parameters?

Another way to ask it:  Assume a modular synth.  You build up a set of
modules and a patch.  Now you want to save the state of this plugin.  The
state of the plugin is no longer just the state of the parameters.  It is
also the state of the module list.  So the module list is actually part of
the patch state.

> In your case (modular synths etc), if you delete a filter (and hence it's
> parameters), it's OK for the host to discard all reference to those
> parameters.  Not so complicated. Most hosts wouldn't need to re-instantiate.

Why is that different from changing the filter-type on a large
semi-modular like Albino?

> Changing the number of audio inputs is a second issue.  In my host that
> definitely needs a re-instantiation.

Well, it was discussed earlier (Ron brought it up) that it needs to be
ok'ed by the host before IO configs change.

> Like I said, I am happy to listen to other views..I am not dead against
> dynamic parameters.  I'm just always thinking "what's the easiest way to do
> this?, do we really need this feature?, can we simplify"

I agree completely.

What I like about the modules approach I described before is that it is
largely host-based (It might come from a custom GUI, but the host does
it).  The host sees the list of modules available on a plugin.  The host
is responsible for telling the plugin when to change it's modular config.
The host is responsible for storing/loading modular state.  It does not
handle the case of a plugin dynamically hiding/unhiding some parameters.

Here's a flipped model.  Make the plugin do everything.  When the config
wants to change, the plugin issues a 'gestalt' request (or something).
Gestalt means that the host must re-query the plugin.  Anything might have
changed - parameter list, parameter meta-data, IO configs, etc.  The
module state must be some extra piece of state information that is
saved/loaded with the parameter state.

So what use cases do we have for this so far?

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 can 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.


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