LowPassFilter coefficients incorrectly calculated about mozzi HOT 4 CLOSED

The fix for q is straightforward, requiring a fix-point divide to be defined and used (and be sure to use f, not cutoff in the calculation).

The fix for f is depends on what the API should achieve:

1. Leave it as it is: The filter has a cutoff range of 0Hz to AUDIO_RATE / 2π - or about 2.6kHz for the 16384kHz sample rate, 5.2kHz with 32768kHz sample rate.

2. Push the available range by scaling the input by 1.5.

f = 1.5 * cutoff

This still makes use of the sin x = x approximation, though pushes into less accurate territory. This raises the range to 3.9kHz for the lower sampling rate, 7.8kHz for the higher.

3. The range is still rather low for a low pass filter - there is no way to set the center frequency high enough that it effectively goes away. You can solve this by increasing the range again:

f = 2.0 * cutoff

Now the input parameter, cutoff, in the range 0 ~ 1 does drive the filter from 0Hz to Nyquist. However, it is neither linear nor exponential in frequency, and more than half its range is in in the high end of the spectrum

For all of these, adjustments need to be made for the fixed point arithmetic, since values can be more than 1.

from mozzi.

Hi,

Thanks for your input, and sorry for the late reply!

If I understand well, there are basically two problems with the current implementation:
(1) fb = q + q * (1 - f) should be fb = q + q / (1 - f)
(2) f = cutoff should be (ideally) f=2 * sin(pi * cutoff / samplerate)

I think the LowPassFilter is not the only one with this problem, StateVariable is using the same equations.

Weirdly, I think (1) is an harder fix than (2): division a notoriously costly on small MCU so just replacing the multiplication by a division won't do the trick on the performance side I think.
Actually, (2) might be solved by calculating the good value (with the sin), maybe using one of the wavetable already embedded in Mozzi. This might increase memory consumption a bit…

I will start digging into it and will keep you updated!
Best,

from mozzi.

Okay, I have an idea, will try to implement and test it soon.

Basically, the idea would be to use the limited development (if someone can enlighten me with the correct English translation, I'll be grateful…) of 1/(1-f):

Close to f=0 we have: 1/(1-f) \approx 1+f (+f^2). Hence, fb=q+q/(1-f) \approx q + q (1+f (+ f^2)). At the first order (without the square), this will not be very correct for large f, but will be closer to the ideal value already, without added computational cost.

from mozzi.

On behalf of Mozzi users, thanks to @mzero and @tomcombriat for your insights and work on this.

from mozzi.