[PD] could vanilla borrow iemlib's hi pass filter recipe?

katja katjavetter at gmail.com
Sat Oct 15 16:59:07 CEST 2016


Thanks for your pointers Christof. The recipe you mention from
arpchord.com is different than iemlib's, but yields identical
normalization and feedback coefficients, thus the same beautiful
response. As you say, what's in the textbooks is common knowledge and
can be used by everyone. Now I'll try to get the same result in C.

By the way, [iemlib/hp~] seems to recalculate coefficients for every
dsp vector which explains the higher CPU load.

Katja

On Sat, Oct 15, 2016 at 1:59 PM, Christof Ressi <christof.ressi at gmx.at> wrote:
>> If iemlib's license allows to use the recipe in BSD
>
> IMHO, the correct formular for the cutoff frequency below (which I guess is also used in [hp1~] since the frequency response is the same) is 'common knowledge', so I don't think you'd have to pay attention to any licence.
>
>
>> Gesendet: Samstag, 15. Oktober 2016 um 13:52 Uhr
>> Von: "Christof Ressi" <christof.ressi at gmx.at>
>> An: katja <katjavetter at gmail.com>, "Miller Puckette" <msp at ucsd.edu>
>> Cc: pd-list <pd-list at iem.at>
>> Betreff: Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?
>>
>> > But coefficients aren't recalculated so
>> > often, therefore this difference will be negligible.
>>
>> That's a good point. You're right that both involve a feedback and feedforward, so I'm wondering why [hp1~] needs more CPU... otherwise, iemlib's filters are very efficient.
>>
>> Anyway, I researched a bit and found the reason why the frequency response of Pd filters seems 'wrong':
>>
>> Miller uses a formular for calculating the cutoff frequency which is taken from analog filters but is not really adequate for digital filters since it doesn't reflect the cyclic nature of the digital domain (although you can see it in some articles on digital filters).
>>
>> Let's take [hip~] as an example:
>>
>> the formular for a 1-pole 1-zero highpass goes:
>> y[n] = (x[n] - x[n-1]) * (1 + k) / 2   +   k * y[n-1]
>>
>> Miller calculates the position of the pole with
>> k = 1 - (fc * 2*pi / SR).
>>
>> The correct formular, however (if you want the frequency response to be zero at Nyquist!), would be
>> k = (1-sin(a))/cos(a), where a = fc * 2*pi / SR.
>>
>> You can find it here: http://www.arpchord.com/pdf/coeffs_first_order_filters_0p1.pdf
>>
>> BTW, the reason why [hip~] seems to get stuck at 7018 Hz is because Miller clips the coefficient below 0, so it never reaches -1 (where the gain would be all zero).
>>
>> Also, there is another approximation with a similiar behaviour, which goes like this:
>> k = e^(-2*pi*fc/SR). I could find it here: http://www.dspguide.com/ch19/2.htm
>> Here, the pole can only move from 1 to 0 and doesn't ever reach -1 as well.
>>
>> Now, is the behaviour of [hip~] 'wrong'?
>> If you define at 1-pole 1-zero high pass filter as something which passes everything at fc = DC and blocks everything at fc = Nyquist, then I'd say yes.
>> If it should roughly model an analogue filter (where the cutoff frequency can go up to infinity) for low cutoff frequencies only, then I'd say no.
>>
>> Also, as I tried to point out, this issue with the cutoff frequency is true for all Pd filters!
>>
>> So I think this behaviour should either be changed (great, if Katja is willing to submit a patch!) or documented in the help patch (gain is not 0 at Nyquist!).
>>
>> I'm not an engineer or any expert on filter design. It's just my two cents :-)
>>
>> Christof
>>
>>
>>
>>
>>
>> > Gesendet: Samstag, 15. Oktober 2016 um 11:39 Uhr
>> > Von: katja <katjavetter at gmail.com>
>> > An: "Christof Ressi" <christof.ressi at gmx.at>
>> > Cc: pd-list <pd-list at iem.at>
>> > Betreff: Re: [PD] could vanilla borrow iemlib's hi pass filter recipe?
>> >
>> > I'm pretty confident [hip~] would not loose its efficiency when using
>> > iemlib's recipe. Both hi pass filters have a feed forward and feedback
>> > component, with coefficients for normalization and feedback.
>> > Calculation of these coefficients is a bit more involved with iemlib's
>> > recipe, using trig functions. But coefficients aren't recalculated so
>> > often, therefore this difference will be negligible.
>> >
>> > To reassure, it is not my intention to spark another 'what's wrong
>> > with pd' thread. If iemlib's license allows to use the recipe in BSD
>> > code I'll try patch the C of [hip~] and submit on the tracker for
>> > review. Who knows, it may be a no-brainer.
>> >
>> > Katja
>> >
>> >
>> >
>> >
>> >
>> > On Sat, Oct 15, 2016 at 2:34 AM, Christof Ressi <christof.ressi at gmx.at> wrote:
>> > > There are a number of big problems with all build-in filters in Pd (expect for the raw filters).
>> > >
>> > > Problem number 1:
>> > > [lop~] and [hip~] both use a weird (you could also say: wrong) formula for the cutoff frequency which makes them gradually converge to a fixed output state (reached by about 7000 Hz). The same is true for [vcf~] and [bp~] with Q <= 1. Therefore the actual cutoff frequency is only correct for very low frequencies and approximately gets more and more off until it doesn't move at all.
>> > >
>> > > Problem number 2:
>> > > [bp~] and [vcf~] don't have zeros at DC and Nyquist. For low Q values, the slope is different for each side and changes with frequency.
>> > >
>> > > Problem number 3:
>> > > the gain at the center frequency is not 1 for both [bp~] and [vcf~]. It rather depends on frequency and Q. [bp~] even has has a gain of 2 for Q <= 1!
>> > >
>> > > I did some FFT plots, see the attachment.
>> > >
>> > > I remember Miller saying somewhere that these filters are not designed for high cutoff frequencies - but even for low frequencies, the behaviour of [bp~] and [vcf~] is horrible. I can see these filters are mere approximations to reduce CPU usage.
>> > > [hip~] is indeed much more efficient than iemlib's [hp1~], so it's well suited for DC removal (but not much else).
>> > > [bp~] only is a little bit more CPU friendly than iemlib's [bp2~] - but the latter one has a correct and stable frequency response.
>> > > [vcf~], however, is a real CPU sucker!!! 100 [vcf~] objects need 3,40% on my laptop whereas 100 of iemlib's [vcf_bp2~] only need 1,80%! But you have to consider that [vcf_bp2~] not only acts correctly but lets you set the Q at audio rate. The high CPU usage of [vcf~] seems like a bug to me...
>> > >
>> > > I only use the vanilla filters for the most basic stuff like DC removal and smoothing. I guess these are the use cases which Miller had in mind and that way [lop~] and [hip~] have their justification (although there should be some more warning about the 'wrong' frequency response in the help file).
>> > > But [bp~] and [vcf~] are almost unusable IMHO and should probably be replaced by better filters in the future (while keeping the old ones for compatibility reasons).
>> > >
>> > > Christof
>> > >
>> > >
>> > >> Gesendet: Freitag, 14. Oktober 2016 um 23:51 Uhr
>> > >> Von: katja <katjavetter at gmail.com>
>> > >> An: pd-list <pd-list at iem.at>
>> > >> Betreff: [PD] could vanilla borrow iemlib's hi pass filter recipe?
>> > >>
>> > >> In pd 0.47.1 [hip~] is still not perfect. Attenuation at cutoff is not
>> > >> constant over the frequency range: -6 dB with cutoff=SR/8, -3 dB with
>> > >> cutoff=SR/4, 0 DB with cutoff=SR/2. In contrast, iemlib's [hp1~] has
>> > >> -3 dB at cutoff consistently.
>> > >>
>> > >> Could vanilla pd implement iemlib's hipass filter recipe? I don't know
>> > >> if the license also covers the math. Documentation in
>> > >> https://git.iem.at/pd/iemlib/tree/master points to external literature
>> > >> for part of the math (bilinear transform). I've implemented the recipe
>> > >> with vanilla objects for comparison, see attached.
>> > >>
>> > >> Katja
>> > >> _______________________________________________
>> > >> Pd-list at lists.iem.at mailing list
>> > >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>> > >>
>> >
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
>>



More information about the Pd-list mailing list