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

Sat Oct 15 23:08:39 CEST 2016

And my learning for the day is done.

Thanks both

On 15 October 2016 at 15:59, katja <katjavetter at gmail.com> wrote:

> 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
> >>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20161015/06fcb4e6/attachment-0001.html>