Re: [PD] [lop~] coefficient calculation
Can you make a clone of [moog~] while you're at it? :) On Jul 18, 2014, at 11:58 PM, via Pd-list pd-list@lists.iem.at wrote: From: Alexandre Torres Porres via Pd-list pd-list@lists.iem.at Subject: Re: [PD] [lop~] coefficient calculation Date: July 18, 2014 at 11:44:47 PM EDT To: Joe White white.j...@gmail.com Cc: pd-list pd-l...@iem.at Reply-To: 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 Dan Wilcox @danomatika danomatika.com robotcowboy.com ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [lop~] coefficient calculation
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
Re: [PD] [lop~] coefficient calculation
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
Re: [PD] [lop~] coefficient calculation
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
Re: [PD] [lop~] coefficient calculation
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
Re: [PD] [lop~] coefficient calculation
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 ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management - http://lists.puredata.info/listinfo/pd-list
Re: [PD] [lop~] coefficient calculation
Thanks for the reply Miller. Out of curiosity, would you *not *recommend using it for any kind of audio data that goes to the output? Up until this realisation I would rely quite heavily on [lop~] for any kind of sweepable (or static) low pass filtering needs, and I'm pretty sure many of the people I've worked with would do the same. If that's the case could you recommend an alternative? It was only from your recent email that I realised [vcf~] had both a band-pass and low pass output, I had always assumed it was only band-pass. 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' :) Looking forward to hearing your input, Cheers, Joe 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