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
