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

[Stefano D'Angelo]

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

But how do you know they are 2 eqs if you don't know their impulse response?
Maybe you mean that this happens when they are two instances of the same object?

> >> * 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)

Ok.

> >> 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"?

It's what I'm working on and what we're talking about!
I called such thing NASPRO which is a recursive acronym for NASPRO
Architecture for Sound PRocessing Objects. The real "naspro"
(pronounced like 'nnashpro) is a typical southern italian icing used
for sweets :-)

> >> 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