Jeff McClintock wrote:
>>>I actually don't know how many
plugins are LTI, but, for example, a
>>>lot of delays, reverbs, choruses, eq. filters, compressors,
modulators
>>and "sound mixers" should be, and that's quite enough after all.
Yeah, It's a good optimization. The SynthEdit plugin API supports
inputs being flagged as 'linear', if several such plugins are used in
parallel they are automatically collapsed into a single instance which
is fed the summed signals of the original plugins. Plugin are
collapsed only when their control inputs are the same.
BEFORE optimation:
[plugin]-->[delay1]------>
[plugin]-->[delay2]-/
AFTER:
[plugin]--->[delay1]--->
[plugin]-/
e.g. two parallel 100ms delays are combined. Two different length
delays aren't.
This is most useful in synth patches where each voice is an
identical parallel sub-patch.
Jeff McClintock
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.
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.
Stefano