On 9/8/2009, "Fons Adriaensen" <[email protected]> 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 [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
