static vs dynamic filters

[tulamide]

Here I am once again outing me as a dumb idiot when it comes to filters (or generally higher maths dsp):

What exactly is the difference, if the same filter exists in two versions, as 'static' and 'dynamic'? Is it only to emphasize that the dynamic one is better modulatable? So, if I do changes to the cutoff, but only manual, the static version is the better choice, and if I modulate it at, say, 2 Hz, the dynamic version is better suited?

If so, what changes occur between the versions, if I just have a fixed cutoff and use both of them (does one have a better sound output than the other?)

[KG_is_back]

Generally, static filter refers to filter which has fixed/hard-coded transfer curve, meaning it can't be changed without recompiling the code.
Dynamic filters have actual inputs (like cutoff frequency, Q, etc.) which allow you to modify and modulate the curve.
Sometimes filters can be semi-static, meaning their curve can be set when they are initialized (in flowstone it is implemented via stage(0) code). Or update in regular longer intervals.

If you use dynamic filter in a place where static would suffice, the result should be the same (sound-quality-wise). Only difference is that CPU consumption will be higher, due to dynamic filter constantly updating its coefficients (which naturally takes some CPU - in fact, usually more then the actual filtering part).

Naturally, there is a myriad of optimizations that can be done on dynamic filters, to make them behave more efficiently.
Some contain " hop" in the coefficient calculation, so that they don't update their coefficients constantly. This effectively means you are down-sampling the input parameters, which may cause problems with high-modulation-frequencies. Also, it does not stop the filter from updating coeffs, when parameters aren't changing.
Another way is to make the coefficient update conditional (condition being, the change of input parameters). This saves quite a lot of CPU when parameters aren't changing and causes occasional CPU spikes when they do. It however fails when parameters are constantly modulated - it just updates them constantly saving no CPU at all.

Simply, there is no go-to solution that fits all scenarios. Rule of thumb is, if the filter is not expected to change, use static, because it saves CPU.

[tulamide]

That's exactly the kind of description, I was looking for. I know you don't care much for gratitude, but still I want to thank you

[RJHollins]

we 2nd the Thank-you's.

[also ... thanks to 'T' for asking the question ... I didn't know the reasoning].

[martinvicanek]

I use the term static filter in a loose sense for mostly static filter, i.e. a filter with rarely changing parameters, and if they change timing is not so important. This includes truly static filters as well as filters controlled by manual user interaction. My static filters have green inputs for the filter parameters so filter coefficient calculations are triggered only if there is a change to save CPU otherwise.

Obviously (my) static filters are not suited for modulation.

For non-changing filter parameters, stream processing is identical for static vs dynamic fiter variants, there is no difference in sound.

In case of doubt use the dynamic filter (and buy a more powerful computer ).

[tulamide]

My static filters have green inputs for the filter parameters so filter coefficient calculations are triggered only if there is a change to save CPU otherwise.

That's good to know, because it's indeed your optimized LP and HP filters that I'm using

In case of doubt use the dynamic filter (and buy a more powerful computer ).

In my current test configuration (which is an audio effect, not an instrument) I use 2 10-pole-hp and 2 10-pole-lp static filters and the complete audio section -which is more than just that 4 filters- uses about 1.4% according to Flowstone. I haven't looked at the task manager yet, but I'm confident that it will be a low-cpu-effect in the end

Since you already posted here, may I ask a question regarding the poles? I understand that the number of poles is associated with the steepness of the curve, where the filter cuts off. The poles have somehow to do with the equation used. So it is not always possible to tell a dB/Oct value for filters. Would it be ok to use a decription of 6 dB/Oct per pole in this special circuit of only LP and HP filters? So that instead of 2-pole, 4-pole, 6-pole, etc., I can present the user with a switch that tells 12 dB, 24 dB, 36 dB, 48 dB and 60 dB?

[martinvicanek]

Yes, that's correct, stacking filters of one kind as you do amounts to adding slopes (dB per octave), with 6dB/octave per pole or 12 dB/octave per biquad. (This is somewhat simplified, but useful as a rule of thumb, and certainly good enough for rock n roll! )

[tulamide]

Thanks a lot! So let me get rock'n'rolling