> 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).
how about bob~? 2016-10-14 21:34 GMT-03:00 Christof Ressi <christof.re...@gmx.at>: > 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