The funny (sad?) thing is that you’ve spent a lot of time trying to get this JUCE filter to work but you could have implemented the whole thing by hand in a fraction of the time. This isn’t to throw shade on you, just to say that the JUCE dsp module isn’t necessarily the easiest to use. Under the hood it’s just a basic biquad filter.
This dividing by b0 can be avoided by rewriting the coefficient calculation math but in this case I’m using the peaking filter formulation from the RBJ cookbook, which includes b0.
Honestly I asked myself that question before starting: write it from scratch (good for learning and knowing exactly what’s going on) or use the DSP module (better implementation, works out of the box)? I’ve always been taught not to reinvent the wheel and use library code where possible so I opted for the DSP module.
But you’re right here, for my simple use case what you shared seems to be enough and without all the extra complication.
I think I had a similar problem in the past, if I remember correctly I was writing a delay, tried using the built-in DSP classes but ran into issues/limitations, so eventually I wrote my own circular buffer (complete with fractional delay) and it was all sorted (with much less effort than expected).
Not sure if that’s necessarily best practice, but I agree that sometimes it can just be the simplest thing to do (plus a good way to learn how things work under the hood and to have more control if needed).
Thanks again for all the advice, much appreciated!
If you look at the source code, the resulting newCoefficients[] must be identical. But I do recommend using double precision (at least when calculating coeffs).
And I also agree with @kerfuffle . As I said before, if you change coeffs very fast, the redundant checks in juce::dsp::IIR may hurt the performance a little bit. I use my own IIR filter to improve efficiency: