9 Aug
2009
9 Aug
'09
8:10 p.m.
On 9/8/2009, "Fons Adriaensen" <fons(a)kokkinizita.net> wrote:
2. The situation is already different for e.g. a
compressor
or limiter. In that case you would expect the same gain profile
on all channels, probably determined (but not always) by the one
with the highest level. In other words the channels *do* interact.
...
Clearly at least (2) requires the plugin to be aware of
the situation,
and to be designed to handle it. That in turn is possible only if the
plugin interface can represent this case. But also case (1) would
benefit from being aware of the multichannel use: in many cases the
bulk of the work is not the real signal processing but things like
limiting the rate of change of parameters, computing and interpolating
internal parameter values etc. and all of that can be shared if the
plugin standard is designed for it. It's not possible to 'retrofit'
this to existing mono plugins by an extension. And finally, a plugin
that would do the right thing in case (2) would fail if used in case
(3) - it again needs to be aware of being used in this role.
some probably bad ideas:
rather than trying to get a number of instances of the same plugin
sharing data, is there any way for having a dynamic number of ports
created within one plugin depending on the context (noof channels) it is
placed in?
slightly different maybe if you've got 4 ins two outs some kind of
switchery for routing/mixing within the plugin [ and (i'm not sure this
is a good idea) the ability to handle connections (a port for a port)
to i/o s within a plugin (ie dropdown combo box etc to select the in to
use for this in or the out to use for that out in the plugin itself). ]