19 Feb
2007
19 Feb
'07
2:14 p.m.
2007/2/19, Camilo Polyméris <cpolymeris(a)gmx.net>et>:
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?
Ok. Filter chains without outputs nor side-effects. (Like optimizing
away pure functions)
Ok.
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 :-)
Stefano D'Angelo wrote:
Actually, *
:-)
2007/2/19, Camilo Polyméris
<cpolymeris(a)gmx.net>et>:
I meant Jeff's idea: the simplification of
parallel filters. He
mentioned the SynthEdit API using it.
Stefano D'Angelo wrote:
Maybe too specific... maybe also plugins with different control inputs
can be merged, I must see this. 2007/2/19, Camilo Polyméris
<cpolymeris(a)gmx.net>et>:
> 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.
Added = multiplied :-) * If two serial filters are LTI, and their impulse
response is unknown,
they can be swapped.
Yes, but why? * 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?
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.
>> 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