And my learning for the day is done. Thanks both
On 15 October 2016 at 15:59, katja <[email protected]> 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 <[email protected]> > 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" <[email protected]> > >> An: katja <[email protected]>, "Miller Puckette" <[email protected]> > >> Cc: pd-list <[email protected]> > >> 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 <[email protected]> > >> > An: "Christof Ressi" <[email protected]> > >> > Cc: pd-list <[email protected]> > >> > 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 < > [email protected]> 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 <[email protected]> > >> > >> An: pd-list <[email protected]> > >> > >> 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 > >> > >> _______________________________________________ > >> > >> [email protected] mailing list > >> > >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/ > listinfo/pd-list > >> > >> > >> > > >> > >> _______________________________________________ > >> [email protected] mailing list > >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/ > listinfo/pd-list > >> > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/ > listinfo/pd-list >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
