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
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
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 msp@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 ->
On Wed, May 21, 2014 at 5:31 PM, Joe White white.joe4@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 msp@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 ->
-- Follow me on Twitter @diplojocus
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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 cgclepper@gmail.com wrote:
On Wed, May 21, 2014 at 5:31 PM, Joe White white.joe4@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 msp@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 ->
-- Follow me on Twitter @diplojocus
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
as far as i know, [expr] went from charcoal to grey, didn't it?
On Fri, May 23, 2014 at 8:06 PM, Joe White white.joe4@gmail.com 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 cgclepper@gmail.com wrote:
On Wed, May 21, 2014 at 5:31 PM, Joe White white.joe4@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 msp@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 ->
-- 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
Ahhh.... cool :)
On 23 May 2014 13:12, i go bananas hard.off@gmail.com wrote:
as far as i know, [expr] went from charcoal to grey, didn't it?
On Fri, May 23, 2014 at 8:06 PM, Joe White white.joe4@gmail.com 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 cgclepper@gmail.com wrote:
On Wed, May 21, 2014 at 5:31 PM, Joe White white.joe4@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 msp@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 ->
-- 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
No problem, Joe. I took everything from the canonical RBJ source: http://www.musicdsp.org/files/Audio-EQ-Cookbook.txt
I didn't do the shelving because they are a pain in ass to do using expr.
I should mention that these calculate the bandwidth of the filter and not Q. I find it easier for bandpass and peaking EQ to use bw, but to have resonance for a hi/lopass filter the values need to be low ( bw < 1). The abstractions should include the expr to do Q just not hooked up.
Chris
On Fri, May 23, 2014 at 7:06 AM, Joe White white.joe4@gmail.com 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 cgclepper@gmail.com wrote:
On Wed, May 21, 2014 at 5:31 PM, Joe White white.joe4@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 msp@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 ->
-- 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
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.
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 cgclepper@gmail.com wrote:
On Wed, May 21, 2014 at 5:31 PM, Joe White white.joe4@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 msp@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 ->
-- 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
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 fbar@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 cgclepper@gmail.com wrote:
On Wed, May 21, 2014 at 5:31 PM, Joe White white.joe4@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 msp@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 ->
-- 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 ->
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.joe4@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 fbar@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 cgclepper@gmail.com wrote:
On Wed, May 21, 2014 at 5:31 PM, Joe White white.joe4@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 msp@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 ->
-- Follow me on Twitter @diplojocus
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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 porres@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.joe4@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 fbar@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 cgclepper@gmail.com wrote:
On Wed, May 21, 2014 at 5:31 PM, Joe White white.joe4@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 msp@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 ->
-- Follow me on Twitter @diplojocus
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list