[gmpi] Re: 3.11 Parameters

On Wed, Mar 31, 2004 at 09:41:27AM -0500, Ron Kuper wrote:
> IMO this needs to be a host responsibility.  In SONAR we call these
> "gangs" (to the user they called "groups").  Controls can be ganged with
> absolute, relative or inverse relationships in our app.  I can imagine
> other hosts wanting to gang in other more interesting ways.   

Definingthe actual relationship could get fugly.  First off, I need to know
that spontaneous parameter changes are actually needed and required.  If
true, I want to be convinced that a plgin needs to state this a priori.  Then
I'd be curious to know why the funtional relation needs to be defined. :)

> As much as I want to say "no", I think we have to say "yes."  There are
> some analog modeling synths out there that expose many hundreds of
> parameters, most of them exposed only because the user might enable a
> particular oscillator in the synth.  This forces the user to see all
> kinds of irrelevant parameters when creating automation data in the
> host.

That is an issue I had not even considered.  I had considered modulars where
you might add a new oscillator or two or ten.  But yes - use my favorite VST
as an example.  Albino.  It has 4 oscillators modules.  Each osc can be one
of threetypes.  Each type has different params.  It has 2 filter modules,
each of which can be one of two types.  It has 2 FX modules, each of which
can be one of 6 types.  The parameter list for automation is something like
500 parameters.

> Also, plugins and synths may create inputs and outputs dynamically.  If
> "output gain" is a parameter, it stands to reason that this parameter
> needs to be created dynamically.  Otherwise the plugin needs to declare
> in advance what its maximum # of outputs would be.

Well, if I/O is only defined at instantiation, the plugin could create a
"static" I/O and parameter list at instantiation time.  The host would never
see those parameter lists change, but the plugin would not get to make some
assumtions.  Further, it gets to be  lot more awkward when I/Os are not
simply mono ins/outs.

I think (only read docs once) AU allows you to pass the number of ins/outs
as an argument to the instantiate.  How do I ask a GMPI plugin to create 4
mono ins, 8 stereo ins and a 5.1 out?  A lot of the flexibility is gone.

IF AND ONLY IF we decide we need to have I/O and param configs that are not
compile-time-static, then I think it should be fully dynamic.    If we're
going to lose that potential optimization(*), then lets make it worth it.

(*) We don't totally lose the optimization.  If the "modules" approach, a
module may have a fixed number of I/Os.  Simple plugins will only define 1
module and will disallow more than one instance.  The code to operate on a
module IS compile-time static and can be unrolled.  More complex plugs might
have several modules each with an unrolled processing function.

> > Can hidden/not hidden change during runtime (also no)?
> 
> Again, I think we have to say yes.  Same reason as above.

In the "modules" model (gosh, that needs a better name) the parameter list
(and the hidden flags thereon) are static to a module, and the module list
is dynamic.  So not really, but yes. :)

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