Hi List,
I have a working duplicate of GGEE's [lowpass] in purepd, and have noticed an interesting thing on my setup here. GGEE's [lowpass] seems to be sharp by a semitone or so, while the purepd impl produces coefficients which are in tune with a osc~ at the same frequency. This is very obvious when using small bandwidth values. I've verified my omega, alpha, and a0-a2, b0-b2 values against GGEE's lowpass.h/lowpass.c as correct and a perl script doing the same calculations.
The attached .ogg file shows the ggee coefficients in a biquad~ with noise~ running through it, a purepd [lowpass], and then a pure osc~ at the same cuttoff frequency. It switches between the ggee, purepd, and the osc. The attached .pd file can be used to reproduce the behavior.
Can you reproduce this behavior on your machine? GGEE's code appears legit, so I suspect the issues some place else (like samplerate, etc).
Cheers! ~brandon
brandon zeeb wrote:
GGEE's [lowpass] seems to be sharp by a semitone or so
[1] line 68: x->x_rate = 44100.0;
seems to have a hardcoded sample rate, which obviously causes problems when running at other sample rates...
Claude
[1] http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/ggee/f...
On May 18, 2009, at 4:27 PM, Claude Heiland-Allen wrote:
brandon zeeb wrote:
GGEE's [lowpass] seems to be sharp by a semitone or so
[1] line 68: x->x_rate = 44100.0;
seems to have a hardcoded sample rate, which obviously causes
problems when running at other sample rates...
Nice catch. That seems like a bug, no? As far as I know Günter is
missing-in-action on his code in the pure-data SVN, so it seems
appropriate to me IMHO to commit fixes directly.
.hc
Claude
[1] http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/ggee/f...
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
There is no way to peace, peace is the way. -A.J. Muste
Indeed, great catch. I hadn't noticed that line!
On Mon, May 18, 2009 at 4:30 PM, Hans-Christoph Steiner hans@at.or.atwrote:
On May 18, 2009, at 4:27 PM, Claude Heiland-Allen wrote:
brandon zeeb wrote:
GGEE's [lowpass] seems to be sharp by a semitone or so
[1] line 68: x->x_rate = 44100.0;
seems to have a hardcoded sample rate, which obviously causes problems when running at other sample rates...
Nice catch. That seems like a bug, no? As far as I know Günter is missing-in-action on his code in the pure-data SVN, so it seems appropriate to me IMHO to commit fixes directly.
.hc
Claude
[1] http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/ggee/f...
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
There is no way to peace, peace is the way. -A.J. Muste
Btw, this seems to be a feature of almost all of the GGEE biquad coefficient externals. Check line 67 on highpass.c, bandpass.c, equalizer.c, and so forth. I'm not sure how you would want to handle this, but keep in mind it's systemic.
Cheers, ~Brandon
On Mon, May 18, 2009 at 4:30 PM, Hans-Christoph Steiner hans@at.or.atwrote:
On May 18, 2009, at 4:27 PM, Claude Heiland-Allen wrote:
brandon zeeb wrote:
GGEE's [lowpass] seems to be sharp by a semitone or so
[1] line 68: x->x_rate = 44100.0;
seems to have a hardcoded sample rate, which obviously causes problems when running at other sample rates...
Nice catch. That seems like a bug, no? As far as I know Günter is missing-in-action on his code in the pure-data SVN, so it seems appropriate to me IMHO to commit fixes directly.
.hc
Claude
[1] http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/externals/ggee/f...
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
There is no way to peace, peace is the way. -A.J. Muste
brandon zeeb wrote:
Btw, this seems to be a feature of almost all of the GGEE biquad coefficient externals. Check line 67 on highpass.c, bandpass.c, equalizer.c, and so forth. I'm not sure how you would want to handle this, but keep in mind it's systemic.
you would systematically use x->x_rate=sys_getsr().
fgamsdr IOhannes
IOhannes m zmoelnig wrote:
brandon zeeb wrote:
Btw, this seems to be a feature of almost all of the GGEE biquad coefficient externals. Check line 67 on highpass.c, bandpass.c, equalizer.c, and so forth. I'm not sure how you would want to handle this, but keep in mind it's systemic.
you would systematically use x->x_rate=sys_getsr().
Some additional questions:
What about [block~] up/downsampling? does that get taken into account by sys_getsr()? when is it safe/recommended to call sys_getsr()? (I guess in the dsp add method?)
Claude
Claude Heiland-Allen wrote:
IOhannes m zmoelnig wrote:
brandon zeeb wrote:
Btw, this seems to be a feature of almost all of the GGEE biquad coefficient externals. Check line 67 on highpass.c, bandpass.c, equalizer.c, and so forth. I'm not sure how you would want to handle this, but keep in mind it's systemic.
you would systematically use x->x_rate=sys_getsr().
Some additional questions:
What about [block~] up/downsampling? does that get taken into account by sys_getsr()? when is it safe/recommended to call sys_getsr()? (I guess in the dsp add method?)
ok.
sys_getsr() reports the sample-rate of the audio-backend. whatever happens within the patch (up/downsampling) does not affect this value. if you want to get the sample-blocks samplerate, you get this from the t_signal structure (as passed to the dsp callback)
unfortunately, the sr in this structure always munges in the overlap factor...
vfsamsdr IOhannes
-
brandon zeeb -
Claude Heiland-Allen -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
martin brinkmann