[linux-audio-dev] processing plugin standard wrapper

[Camilo Polyméris]

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