[linux-audio-dev] Re: processing plugin standard wrapper

Camilo Polyméris cpolymeris at gmx.net
Mon Feb 19 16:36:31 UTC 2007


Stefano D'Angelo wrote:
> 2007/2/19, Camilo Polyméris <cpolymeris at gmx.net>:
>> 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
>

Yes, I agree I think if one comes up with a couple of "rules" like that, 
it could be possible to design a system which automatically simplifies 
processing networks.
To recap:
* If two parallel filters have equal control inputs and their outputs 
are summed, replace with one filter and feed with summed inputs.
* If two serial filters are LTI, they impulse response can be added to 
one filter.
* If two serial filters are LTI, and their impulse response is unknown, 
they can be swapped.
* Filter "classes" could know how to merge to instances into one. Those 
instances may even cancel each other out.
* Remove filter chains which have no outputs.
etc... With a little thinking and some formal work, one could come up 
with more ideas like those.
Software like puredata and jMax (which use such "common basic pieces" in 
many diferent configurations) could benefit from such a system. I looked 
at their websites, but could not find any references to similar ideas.

Camilo



More information about the Linux-audio-dev mailing list