IIR Filter: Utility, Audio Source or DSP Processor?

Hi, first post, so please have mercy on me :sweat_smile:
I’m asking this question referring to IIR filters, but I have the same doubt over other tools.

I see IIR filters are implemented as an utility class, as an AudioSource class, and also as a DSP Processor class. How am I supposed to choose between these implementations? I suppose it depends on the context, but is there a rule of thumb for discern the most appropriate one?

E.g.: I need to add a lowpass filter in a plugin, supporting both mono and stereo buses, with the cut-off frequency controlled by a parameter (without smoothing), and without the need to change the processing chain inside my processBlock method… How am I supposed to choose the right class in order to produce the most readable code?

And what about overhead/performance aspects?

Thanks in advance for the suggestions!

I think I may have figured it out by myself by looking at the source code… :duck:

I noticed that:

  • IIRFilter is an implementation of a common biquad filter. Very nice. Now I can trust it :stuck_out_tongue_closed_eyes:.
  • IIRFilterAudioSource is a decorator based on IIRFilter; thus, to use a IIRFilterAudioSource, I have to wrap my existing code into an AudioSource.
  • IIRFilterAudioSource is initialized with a pair of filters (stereo by default) and then the number of filters is increased in getNextAudioBlock if needed. Bold, but effective.
  • dsp::IIR::Filter is a quite different implementation, supporting higher orders, very flexible, with a more functional scent (?).

So I suppose that:

  • I shall use IIRFilter if I’m building something simple, with a “bottom up” approach (I’m probably going to do this, taking some inspiration from the implementation of IIRFilterAudioSource).
  • If I already rely on AudioSources, it is easier to stick with them.
  • DSP classes look very powerful, but requires the context to be ready for them (pun intended), a cost which is not worth paying, given my needs. (nevertheless it looks interesting for more complex projects)

Please correct me if I’m wrong!

I think you figured it all out very well.
Two additions:
The IIRFilter is an older implementation, the dsp::IIR was added later when juce5 came out.

I don’t think the ProcessorContext is much of an overhead, it is necessary, because the new dsp module uses AudioBlocks, which is just referring audio data, versus the AudioBuffer usually owns the sample data (with a few exceptions).

The new approach has two advantages: it is more flexible thanks to the AudioBlock and the dsp::ProcessorChain can optimise at compile time thanks to the template approach.

Thanks @daniel!
Since I’m mainly writing plugins it is more natural for me to deal with references to AudioBuffers, but I’ll dig into those AudioBlocks to see if I like them as well :grin: