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

[Camilo Polyméris]

Stefano D'Angelo wrote:
> 2007/2/19, Camilo Polyméris <cpolymeris at gmx.net>:
>> 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.
>
> Maybe too specific... maybe also plugins with different control inputs
> can be merged, I must see this.
I meant Jeff's idea: the simplification of parallel filters. He 
mentioned the SynthEdit API using it.
>
>> * If two serial filters are LTI, they impulse response can be added to
>> one filter.
>
> Added = multiplied :-)
Actually, *
>
>> * If two serial filters are LTI, and their impulse response is unknown,
>> they can be swapped.
>
> Yes, but why?
That, per se, is no optimization, but moving stuff around can help 
making the other rules apply.
Like, if you have:
    eq -> LTIfilter -> eq ->
you can first swap the first two:
    LTIfilter -> eq -> eq ->
and then reduce the second and third:
    LTIfilter -> sum_of_eqs ->
>
>> * Filter "classes" could know how to merge to instances into one. Those
>> instances may even cancel each other out.
>
> Yes
>
>> * Remove filter chains which have no outputs.
>
> Absolutely not: what about a GUI oscillator?
>
Ok. Filter chains without outputs nor side-effects. (Like optimizing 
away pure functions)
>> etc... With a little thinking and some formal work, one could come up
>> with more ideas like those.
>
> I think too that this is an interesting path to follow: NASPRO (the
> wrapper) will absolutely go this way, just after wrapping LADSPA,
> DSSI, LV2 (without extensions) and similar.
> When LV2 extensions will be implemented then work on these stuff will 
> begin.
>
What's "naspro"?
>> 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.
>
> Good, another use for it :-)
>
> Stefano
>