Three ways to make IIR-filter, which to choose?

[oortone]

@daniel

If you create the coefficients in the audio thread you should use the heap allocation free version.
Allocating memory from a realtime thread is dangerous, because the allocation can take an indeterministic amount of time. Heap allocations are synchronised with other threads which might not have the same high priority.

I realize I need to revisit this. To make sure I update parameters in a safe way. Hope someone can help me to confirm that I got this right…

I’ve implemented a IIR now in the fashion presented here and I’ve connected one parameter (gain) to the GUI via AudopProcessorValueTreeState as presented in tutorials. But since the parameter itself is of no use fore the processBlock I need to recalculate the IIR-coefficients whenever the parameter changes.

However I thought I was clever putting this calculation in a parameter callback using juce::AudioProcessorValueTreeState::Listener implementing it’s parameterChanged() and reassigning the filter’s (or rather process duplicator’s) state only when the GUI parameter changes.

*filter.state = juce::dsp:ArrayCoefficients<float>::makeHighShelf(....);

However reading this thread I realize this might be dangerous. So, as long as I don’t have too many parameters I guess instead I should call the makeHighShelf
in the audio thread for every processBlock regardless of wether any parameter has been updated or alternatively test for changes somehow there.

Am I on the right track here as long as I don’t use too many parameters? It seems a little bit heavy but maybe it’s ok? I find no other way without implementing rather complicated stuff.