It's been noted that [vcf~] can be obtained with a [cpole~] object - though I didn't do it yet as I find it a bit hard to get to the coeficients from the vcf~ code.
Anyway, if you can get it with a [cpole~] object, it means you could do it with [biquad~] coeficients, right? I suppose so, but then, how exactly? I mean, if I have the coeficients of [cpole~], how do I get to [biquad~]'s? maybe this will help getting biquad's coefficients from [vcf~]'s parameters... maybe not, I don't know, I need help :) thanks 2014-07-19 0:44 GMT-03:00 Alexandre Torres Porres <por...@gmail.com>: > hi all, I've been working on filter patches for my courses and I'm still > failing ti get biquad coeficients from the [vcf~] code. Maybe anyone out > there could help? > > I wanted this to plot the frequency response in realtime... > > the [vcf~] filters aren't in the audio Audio-EQ-Cookbook, and the code > looks a bit too complicated > > thanks > > > 2014-05-26 10:23 GMT-03:00 Joe White <white.j...@gmail.com>: > > Ahh yes of course thanks Frank! >> >> Have you guys checked out this paper on 'High-Order Digital Parametric >> Equalizer Design <http://www.aes.org/e-lib/browse.cfm?elib=13397>'? >> Apparently it reduces the need to cascade filter implementations to achieve >> high orders. >> >> Cheers, >> Joe >> >> >> On 24 May 2014 09:53, Frank Barknecht <f...@footils.org> wrote: >> >>> Hi Joe, >>> >>> versions of these calculations without [expr] are also part of the >>> rj-library as u_lowpass, u_lowpassq etc. These have been taken straight >>> from the Audio-EQ-Cookbook. >>> >>> Ciao >>> -- >>> Frank >>> >>> On Fri, May 23, 2014 at 12:06:45PM +0100, Joe White wrote: >>> > Thanks for the abstractions Chris. Am I correct in thinking the >>> licensing >>> > issues for [expr] have been resolved now? >>> > >>> > Cheers, >>> > Joe >>> > >>> > >>> > On 21 May 2014 23:22, Chris Clepper <cgclep...@gmail.com> wrote: >>> > >>> > > On Wed, May 21, 2014 at 5:31 PM, Joe White <white.j...@gmail.com> >>> wrote: >>> > > >>> > >> >>> > >> >>> > >> Is it intentional to not a bank of go-to filters? [biquad~] is the >>> next >>> > >> one I would go to, but generating your own coefficients isn't >>> that... err.. >>> > >> efficient when you're wanting some that just 'works' :) >>> > >> >>> > >> >>> > > Attached are a set of abstractions wrapping most of the 'Audio EQ >>> > > Cookbook' formulae around biquad~. It would be nice for Pd to >>> include >>> > > something like this. >>> > > >>> > > The only drawback to [biquad~] is it doesn't take audio rate >>> coefficients. >>> > > There are of course externals that do audio rate for cutoff, Q, etc. >>> > > >>> > > Chris >>> > > >>> > > >>> > >> >>> > >> >>> > >> On 21 May 2014 17:31, Miller Puckette <m...@ucsd.edu> wrote: >>> > >> >>> > >>> Hi Joe - >>> > >>> >>> > >>> That code is an approximation that works well for low cutoff >>> > >>> frequencies but badly for high ones. (I should probably warn >>> > >>> about this in the help window... that'll go on my dolist) >>> > >>> >>> > >>> cheers >>> > >>> M >>> > >>> >>> > >>> >>> > >>> On Fri, May 16, 2014 at 12:58:31PM +0100, Joe White wrote: >>> > >>> > Hi, >>> > >>> > >>> > >>> > I've been looking at the [lop~] implementation (Pd-0.45-4) and >>> noticed >>> > >>> > something that seem weird to me. >>> > >>> > >>> > >>> > In d_filter, line 176: >>> > >>> > >>> > >>> > static void siglop_ft1(t_siglop *x, t_floatarg f) >>> > >>> > { >>> > >>> > if (f < 0) f = 0; >>> > >>> > x->x_hz = f; >>> > >>> > x->x_ctl->c_coef = f * (2 * 3.14159) / x->x_sr; >>> > >>> > if (x->x_ctl->c_coef > 1) >>> > >>> > x->x_ctl->c_coef = 1; >>> > >>> > else if (x->x_ctl->c_coef < 0) >>> > >>> > x->x_ctl->c_coef = 0; >>> > >>> > } >>> > >>> > >>> > >>> > >>> > >>> > Is it correct that for: >>> > >>> > >>> > >>> > y[n] = x[n] * a + y[n-1] * b >>> > >>> > >>> > >>> > *a = 2π * Fc / Fs* >>> > >>> > b = 1.0 - a >>> > >>> > >>> > >>> > where Fc is the cut-off frequency and Fs the sampling frequency. >>> > >>> > >>> > >>> > I appreciate the a coefficient is bounded afterwards but >>> wouldn't that >>> > >>> mean >>> > >>> > that Fc values greater than Fs / 2π will have no impact on the >>> sound >>> > >>> being >>> > >>> > processed. >>> > >>> > >>> > >>> > For example if Fs is 44100, then Fc values above ~7020Hz will not >>> > >>> affect >>> > >>> > the filter. >>> > >>> > >>> > >>> > Have I missed something crucial or could this a bug in the code? >>> > >>> > >>> > >>> > The simple IIR filter described in >>> > >>> > http://en.wikipedia.org/wiki/Low-pass_filter suggests that the >>> actual >>> > >>> > coefficient calculation should be more like: >>> > >>> > >>> > >>> > a = 2π*Fc / (2π*Fc + Fs) >>> > >>> > >>> > >>> > Looking forward to understand this more! >>> > >>> > >>> > >>> > Cheers, >>> > >>> > Joe >>> > >>> > >>> > >>> > -- >>> > >>> > Follow me on Twitter @diplojocus >>> > >>> >>> > >>> > _______________________________________________ >>> > >>> > Pd-list@lists.iem.at mailing list >>> > >>> > UNSUBSCRIBE and account-management -> >>> > >>> http://lists.puredata.info/listinfo/pd-list >>> > >>> >>> > >>> >>> > >> >>> > >> >>> > >> -- >>> > >> Follow me on Twitter @diplojocus >>> > >> >>> > >> _______________________________________________ >>> > >> Pd-list@lists.iem.at mailing list >>> > >> UNSUBSCRIBE and account-management -> >>> > >> http://lists.puredata.info/listinfo/pd-list >>> > >> >>> > >> >>> > > >>> > >>> > >>> > -- >>> > Follow me on Twitter @diplojocus >>> >>> > _______________________________________________ >>> > Pd-list@lists.iem.at mailing list >>> > UNSUBSCRIBE and account-management -> >>> http://lists.puredata.info/listinfo/pd-list >>> >>> >> >> >> -- >> Follow me on Twitter @diplojocus >> >> _______________________________________________ >> Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list