> 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 > > >> _______________________________________________ > > >> Pdemail@example.com mailing list > > >> UNSUBSCRIBE and account-management -> > > >> https://lists.puredata.info/listinfo/pd-list > > >> > > > > _______________________________________________ > Pdfirstname.lastname@example.org mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > _______________________________________________ Pdemail@example.com mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list