[PD] could vanilla borrow iemlib's hi pass filter recipe?

[Alexandre Torres Porres]

> 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.ressi at 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 <katjavetter at gmail.com>
> > An: pd-list <pd-list at 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 at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
> >
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/
> listinfo/pd-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20161016/a69905db/attachment.html>