[gmpi] Re: 3.11 topic: Dynamic plugin structure
- From: "Jeff McClintock" <jeffmcc@xxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Tue, 20 Apr 2004 12:33:46 +1200
> Describe channel-ability in more depth? I think the modular approach I
> described is channel-like but gone one small step further.
Channel-ability is a sub-set of modularity. channel = module, except there
is only 2 modules:
- global - stuff that applies to all channels
- per-channel - stuff that applies to each channel
e.g. basic mixer:
Global pins are: "master volume", "Mix-Out"
Per-Channel pins: "Audio In", "Chan Volume", "Mute"
> It (modularity) does add both perceptual and technical complexity, so I
can be talked
> out of it, but it is a good way to get all-in-one functionality.
My mind isn't made up either, but several of the use-cases were stuff like a
plugin providing both a mono and stereo version.
i.e. a "one channel" and a "two channel" version.
In these days of surround-sound, it's nice to generalise the concept so the
same plugin could instansiate say, a 6 channel version.
The reason I used a compressor as an example is because a stereo compressor
internally manages the gain of the two channels toggether. So a stereo
compressor is not the same as two mono compressors. Hence the need for
configurable channel-count.
The other use-case of "complex VA synths (which would otherwise have
hundreds of parameters)." That didn't really make sense to me. Does the
parameter set change?. Does the synth have (for example) 4 parameters on
program 1 and 10 parameters on program 2?
I'm not sure, but that sounds very difficult to manage (from the host's
point of view). Does the UI get re-arranged?, what do automation tracks do
when a parameter disappears?
That's why i think *full* modularity may not make sense.
Jeff
----- Original Message -----
From: "Tim Hockin" <thockin@xxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Tuesday, April 20, 2004 11:25 AM
Subject: [gmpi] Re: 3.11 topic: Dynamic plugin structure
> On Tue, Apr 20, 2004 at 10:56:22AM +1200, Jeff McClintock wrote:
> > Here's a use-case.
> >
> > Compressor Plugin, intended for mono/stereo/multichannel use
> >
> > has 4 pins
> >
> > 1) Attack
> > 2) Release
> > 3) Audio In
> > 4) Audio Out
> >
> > 1 and 2 are "plugin global", 3 and 4 are per-channel.
> >
> > There's only ever one Attack and one Release parameter, no matter how
many
> > channels.
> > 3 and 4 are a set. You can have 1 set of input/output, 2 sets etc.
>
> A fine use case, demonstrates the usefulness of the flexibility.
>
> > plugins should not change their interface after they are instansiated.
>
> I have been thinking of a structural change as an effective
destroy/re-create
> cyle. It may not really need to be SO extreme, but it is definitely not
> something to be done in RT :)
>
> > > A modular model was proposed.
> >
> > Do we need full modularity?, "channel-ability" might be sufficient.
>
> Describe channel-ability in more depth? I think the modular approach I
> described is channel-like but gone one small step further.
>
>
> It does add both perceptual and technical complexity, so I can be talked
> out of it, but it is a good way to get all-in-one functionality.
>
> ----------------------------------------------------------------------
> 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: //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: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
