On 9/8/2009, "Fons Adriaensen" <fons@email-addr-hidden> 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). ]
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Mon Aug 10 04:15:05 2009
This archive was generated by hypermail 2.1.8 : Mon Aug 10 2009 - 04:15:05 EEST