FR: Make IIR Filters Less CPU Intensive / Safety Focused

While I appreciate the approach to the shared coeff pointers etc in the IIR filter DSP, it’s not to the benefit of the user at the end of the day.

Having coefficients call new every time they’re generated, creates substantial overhead on the audio thread. It makes the filter almost unusable in the case of fast modulation, and to make it usable, you need to slow modulation down to the point of it not sounding accurate and nice.

I know the SVF is there, but it’s not as flexible and usable as the IIR class, and it’s good to manage your own smoothing

So, NBD, use the old IIR. Okay, I switch all my old code over the old IIR, then still in that code, there are locks in the set coefficients.

I’m not sure who is generating control signals / changing coefficients from other threads than the audio line, but it seems like we’re slowing down / limiting the code here, in an effort to keep it safe from strange use cases, which at the end of the day, are not benefiting the library and have performance impacts.

Forgive me if i’m incorrect! I just built a very large app which uses upwards of 80 of the IIRs, and switching to the old IIRs and removing the locks, dropped CPU in the app a very significant amount.

Seems like this FR to be more or less a duplicate of or at least related to mine from a few month ago…?
https://forum.juce.com/t/non-allocating-alternatives-for-the-iir-make-functions/

Ohh totally apologies i didn’t see that one!