2007/2/19, Paul Davis <[EMAIL PROTECTED]>:
On Mon, 2007-02-19 at 14:18 +0100, Stefano D'Angelo wrote:
> > How often are more than one plugin with the same control inputs used in
> > paralel? I was rather thinking of colapsing (or swapping) plugins in
> > series. They'd have to be linear and time invariant, of course.
> > Or maybe plugins could 'know' how to colapse themselves, sort of like
> > overriding Plugin::operator+(const Plugin&), to use a C++ metaphor.
>
> Well, stereo sounds passing through mono plugins is one case.
nope. thats not a linear arrangement of the two mono plugins, but a
parallel arrangement. the signal going to each instance of the mono
plugin is different.
I'm obscure even in Italian, I can just imagine how it can sound like
in English :-)
I was not talking about that specific thing, I was talking about a
case which could take benefit of some kind of parallel processing
merging.
> However as Jeff describes this optimization, it is applicable when
> output signals are summed, and I don't know how often it happens.
> Anyway it is another idea to optimize processing for linear plugins,
> definitively not something to discard.
> This makes me think that some common basic "pieces" like mixers and
> delay filters can have special properties which involve even more
> aggressive optimization. Maybe it's worth considering how this special
> blocks could be developed and used.
you can think all you want. unless there a plugin->host callback that
allows the plugin to determine its operating environment in huge detail,
this kind of idea is pretty impossible to make use of.
What?
Once again: misunderstood! These optimizations involve that the
"wrapper" (I should stop calling it this way) knows about the network
of processing objects (read: plugins) and that these last ones contain
"generic" information on their functionality (ex. STFT for LTI proc.
objects).
Then the wrapper takes care of optimizing the net.
Stefano