18 Feb
2007
18 Feb
'07
5:57 p.m.
>>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
18 Feb
18 Feb
6:41 p.m.
2007/2/18, Jeff McClintock <jef(a)synthedit.com>om>:
After the first 40 mails ( :-P ) I still have the impression that this
is a good thing after all and that it is more time-consuming than hard
to do, so I think that if someone joins me we can do all of this
become reality. So here I'm asking once again: does someone work on
this?
Anyway I'm continuously uploading the code I'm working on to the
FreeADSP SVN repository (naspro folder), so that everyone can see how
things are going and can give suggests and/or make arguments and/or
anything.
Right now I've only set up an autotoolized tree (+ doxygen and texinfo
support), wrote some header files and a good piece of the module
loading part (which still has to be refined obviously).
I say it again in case it is not clear: this will NOT be a new plugin
API, since its aim is completely different, it's all about
interoperability among existing standards and, in some future, about
optimization and experimentation/research of new processing paradigms.
Sincerely,
Stefano
>>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 
8:23 p.m.
Jeff McClintock wrote:
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.
Camilo
>>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
19 Feb
19 Feb
9:18 a.m.
2007/2/19, Camilo Polyméris <cpolymeris(a)gmx.net>et>:
Jeff McClintock wrote:
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
>>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
11:37 a.m.
On Mon, 2007-02-19 at 14:18 +0100, Stefano D'Angelo wrote:
nope. thats not a linear arrangement of the two mono plugins, but a
parallel arrangement. the signal going to each instance of the mono
plugin is different.
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.
you can think all you want. unless there a plugin->host callback that
allows the plugin to determine its operating environment in huge detail,
this kind of idea is pretty impossible to make use of.
--p
12:50 p.m.
Stefano D'Angelo wrote:
2007/2/19, Camilo Polyméris
<cpolymeris(a)gmx.net>et>:
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
Jeff McClintock wrote:
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
>>>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
1:15 p.m.
2007/2/19, Paul Davis <paul(a)linuxaudiosystems.com>om>:
What?
Once again: misunderstood! These optimizations involve that the
"wrapper" (I should stop calling it this way) knows about the network
of processing objects (read: plugins) and that these last ones contain
"generic" information on their functionality (ex. STFT for LTI proc.
objects).
Then the wrapper takes care of optimizing the net.
Stefano
On Mon, 2007-02-19 at 14:18 +0100, Stefano
D'Angelo wrote:
> > 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.
nope. thats not a linear arrangement of the two mono
plugins, but a
parallel arrangement. the signal going to each instance of the mono
plugin is different.
I'm obscure even in Italian, I can just imagine how it can sound like
in English :-)
I was not talking about that specific thing, I was talking about a
case which could take benefit of some kind of parallel processing
merging.
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.
you can think all you want. unless there a plugin->host callback that
allows the plugin to determine its operating environment in huge detail,
this kind of idea is pretty impossible to make use of.
1:23 p.m.
2007/2/19, Camilo Polyméris <cpolymeris(a)gmx.net>et>:
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>:
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. Jeff McClintock wrote:
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
>>>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. * 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
1:29 p.m.
On Mon, 2007-02-19 at 18:10 +0100, Stefano D'Angelo wrote:
you don't merge or gain anything with a parallel graph. only serial
ordering is amenable to "optimization", and such arrangements are very
rare.
find me a host author who would want to use such a thing... managing
plugins is a central task of a host, and handing that over to some
"wrapper" that hides information from the host doesn't make the host's
life easier, it makes it more complex.
--p
nope. thats
not a linear arrangement of the two mono plugins, but a
parallel arrangement. the signal going to each instance of the mono
plugin is different.
I'm obscure even in Italian, I can just imagine how it can sound like
in English :-)
I was not talking about that specific thing, I was talking about a
case which could take benefit of some kind of parallel processing
merging. you can think
all you want. unless there a plugin->host callback that
allows the plugin to determine its operating environment in huge detail,
this kind of idea is pretty impossible to make use of.
What?
Once again: misunderstood! These optimizations involve that the
"wrapper" (I should stop calling it this way) knows about the network
of processing objects (read: plugins) and that these last ones contain
"generic" information on their functionality (ex. STFT for LTI proc.
objects).
Then the wrapper takes care of optimizing the net.
1:55 p.m.
Stefano D'Angelo wrote:
Actually, *
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 ->
Ok. Filter chains without outputs nor side-effects. (Like optimizing
away pure functions)
What's "naspro"?
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:
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. 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
* 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
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
6299
days inactive
6300
days old
linux-audio-dev@lists.linuxaudio.org
10 comments
4 participants
participants (4)
-
Camilo Polyméris -
Jeff McClintock -
Paul Davis -
Stefano D'Angelo