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
