> 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.re...@gmx.at>
> An: katja <katjavet...@gmail.com>, "Miller Puckette" <m...@ucsd.edu>
> Cc: pd-list <pd-l...@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 <katjavet...@gmail.com>
> > An: "Christof Ressi" <christof.re...@gmx.at>
> > Cc: pd-list <pd-l...@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.re...@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 <katjavet...@gmail.com>
> > >> An: pd-list <pd-l...@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@lists.iem.at mailing list
> > >> UNSUBSCRIBE and account-management -> 
> > >> https://lists.puredata.info/listinfo/pd-list
> > >>
> > 
> 
> _______________________________________________
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> https://lists.puredata.info/listinfo/pd-list
> 

_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Reply via email to