The filter recipe that Christof pointed to was easy to plug into the C
code of [hip~] and works perfectly. But when looking further in
d_filter.c I came across an approximation function 'sigbp_qcos()' used
in the bandpass filter. It made me realize once more how passionate
Miller is about efficiency. I'm not going to make a fool of myself by
submitting a 'fix' using two trig functions to calculate a filter
coefficient when a simple approximation could do the job. So that is
what I'm now looking into, with help of a math friend: an efficient
polynomial approximation for (1-sin(x))/cos(x).

Katja

On Sat, Oct 15, 2016 at 4:59 PM, katja <katjavet...@gmail.com> 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 <christof.re...@gmx.at> 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" <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