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

>>> Ok, i get the context now. As you say, I'am both teacher and researcher,
>>> but my field is Software Engineering and my knowledge on theoretical DSP
>>> is not that mature, so don't take my DSP related statements so serious.
>>> To my level of knowledge, i could say that most of the plugins are not
>>> just LTI so, the kind of optimization you suggest would be not general
>>> just appliable to consecutive adjacent LTI systems. At the same time is
>>> something that may have a lot of sense in FreeADSP.
>>>
>> 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.
>> Consider that in the case of commonly used guitar effects the only
>> non-linear effects by their nature should be hardware-simulators
>> (valves, amps, etc.), distortions and synths.
>>
>
> Not sure at all, but i thought compressor was an example of non linear
> transformation and they normally have an adaptive behavior which make them
> not time invariant, so you cannot model it as a single H(f). It is very easy
> to find a plugin which has been introduced non-linearity o time-variation
> thought the main function (a filter, chorus, reverb...) is LTI. We are also
> used other kinds of transformations such as sine shifting that are far from
> linear also.
You are right. Compressors are the archetypical examples of non-linear
filters. Delays, reverbs, chori, etc. are non-TI (they depend of past
input).
Still, there may be other properties which could be exploited for
optimization, as Stefano suggests. For example, you could collapse
several equalizers to one filter. Or if two consecutive plugins do FFT,
the first could pass the information to the second in the frequency domain.
Neither of these would work with current plugin architectures, though.
While I didn't think of plugins, but rather of more low-level components
(constructs of an audio-oriented programming language, or similar), I
have also been playing with a similar idea, but have not come to any
conclusions yet. I hope the linux-audio-dev comunity does.

Camilo
Received on Sat Feb 17 08:15:01 2007