[gmpi] Re: 3.11 Parameters

> > Prototypical example: a mixer plugin.  It defines a set of modules:
> >
> > MONO: 1 input, 3 EQ params, a gain param, a pan param
> > STEREO: 2 inputs, 3 EQ params, a gain param, a balance param
> > BUS: 2 outputs, a gain param, a balance param
> >
> > The plugin could have 16 MONO modules and 1 BUS module.  Or it could
have 64
> > STEREO modules, 8 MONO modules, and 4 BUS modules.  All the parameters
(and
> > their types, limits, etc) and all the IOs are know at plugin
instantiation
> > time, but the actual structure of them is flexible.  Does that make any
> > sense?


> I dont think so - it sounds very compicated when you could just declare it
> as N different plugins, which share common code. It places a lot of
> complexity in the hosts instantiation code and plugins that use it.

Agree, dynamic parameters and IO place a huge complexity burden on the host.
The use-case given is a mixer. Mixers are a bad example, most hosts
(Cakewalk,Steinberg, Logic etc) already provide *very* comprehensive mixers.
  If I did have to use this mixer plugin,  I would be happy if it just
offered a handful of alternate configurations (e.g. 8 chan mixer, 24 chan
mixer, and 100 chan mixer).

It's always tempting to be 100% flexible, but it just isn't compelling.  The
user wants a mixer, they want it to be 2 mouse clicks away, they don't want
a lesson in mixer architecture.

Best Regards,
Jeff



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