I’m a little confused…
Is order the number of taps in which case shouldn’t or be named numTaps.
Or is it an order of magnitude as the name suggests in which case if I wanted a 512 tap filter I would supply a value of 9
It would also be nice to have a design high pass method in there as the coefs are easy enough to compute.
From what I learned fhe filter order is a mathematical term describing the highest exponent of the filter‘s transfer function in the z-domain. For an FIR filter, this equals the number of filter taps, so I think the naming is correct from a theoretical point of view?
Yeah I dived into the code and it’s definitely number of taps. I always thought of orders as orders of magnitude. 2 to the power of in most computing cases (or 1 << 8 = 256 taps bitwise which I have seen used to with the variable named ‘order’ in the FFT class somewhere ). Seems a little ambiguous. Was switching from my DSP classes to juce’s own and didn’t make sense. The math for creating the Coefs is pretty much identical and the windowing function selection is handy (hence the switch).
Ah found it here juce_fft
(new FFTConfig (1 << order, true));
As FFT is very similar in some ways to FIR filter and having recently used the FFT class. I did a little dive to make sure I was representing bins to frequency correctly and looking at how the bins were setup I came across this.
