I think the math behind convolution (FIR filters) is simple, unless there's some complexity I'm not aware of.

Here's a nice overview:

http://www.songho.ca/dsp/convolution/convolution.html

Hello Matt,

the basic maths IS pretty simple. Just multiplications and additions.

BUT: if you try to compute long filters (e.g. 65536 taps or even more) then the CPU load will be heavy.

So the solution is to apply a Fast Fourier Transformation. With FFT the convolution process is just a vector multiplication. Then you apply an inverse FFT and get the result back in the time domain.

BUT: also a FFT convolution has its obstacles. Especially if you try to get a low CPU load (to avoid bad influences by CPU jitter) AND still get a low latency. Typically you need to use a buffer (FFT package size), this means you have to collect samples. This causes latency. If the package is too small, then the CPU lod can rise quickly. If the package size is too big, then you get a big latency.

Today there are also zero latency algorithms, but the have to organize a lot of threads with package sizes of different lengths.

If you read about the efforts carried out with Brutefir, see

http://www.ludd.luth.se/~torger/brutefir.html, you will get an idea about. You may furthermore start to analyze JConvolver, see

http://kokkinizita.linuxaudio.org/papers/aella.pdf or

http://kokkinizita.linuxaudio.org/papers/aella-pres.pdf or even the source code, as a zero latency convolver.

You clearly need for each samplerate its own filter according to it. A program like VSTConvolver is working nice but lacks of the automatic switch between music sources with changing samplerates.

In addition you will find fore sure users who like to switch between filter banks for comparison of filters, e.g. blind tests.

And of course you will find requirements where people like to apply multiway solutions = multiple outputs from a single input. Or they like to apply combinations of filtering jobs e.g. filter the left channel and add a filtered right channel. Something like crosstalk cancellation or crosstalk introduction (headphone listening).

So e.g. with a 3-way stereo system and 3 filterbanks and 6 possible samplerates you already have to deal with 108 filter kernels of size 512 kB (65536 taps double precision coefficients) and even more.

Anyway the question brought up by TheLion is interesting and challenging. And there must be some basic program structure. In case of a fixed size partitioned convolution the plugin may read data from two buffers and write to two buffers (bufferswitch) like already known from ASIO interfaces. Of course the plugin must know also about the actua samplerate and the filters to apply. In case of non-partitioned convolution the data stream and the buffer switching will be more complex.

Just as some first comments. Simple solutions are available but users like TheLion will complain about for sure

Uli

www.audiovero.de