Hello,
I was testing the [bandpass] and [notch] object's from "ggee" library, which compute coefficients values for vanilla's [biquad~] and discovered that the center frequency wasn't the one expected, but was shifted something like 10%.
After a few measurement I found that the real center frequency was around 1.08841 upwards the ferquency value set to [bandpass] or to [notch] inlets...
...and I later realized that 48000/44100 = 1.088435... and that on my computer, pd is working at 48000 Hz. So, apparently these objects are calculating the coefficients with an supposed samplerate of 44100 Hz.
(i'm using pd-extended 0.43-4)
cheers,
Raphaël
- Raphaël Ilias phae.ilias@gmail.com [2015-05-02 16:36]:
Hello,
I was testing the [bandpass] and [notch] object's from "ggee" library, which compute coefficients values for vanilla's [biquad~] and discovered that the center frequency wasn't the one expected, but was shifted something like 10%.
After a few measurement I found that the real center frequency was around 1.08841 upwards the ferquency value set to [bandpass] or to [notch] inlets...
...and I later realized that 48000/44100 = 1.088435... and that on my computer, pd is working at 48000 Hz. So, apparently these objects are calculating the coefficients with an supposed samplerate of 44100 Hz.
You are right. I just looked at the source file for one of these objects, and it contains a line
x->x_rate = 44100.0;
So apparently the sample rate for it is hard-coded. I don't know ir Günther is actively monitoring the pd-list, but perhaps someone else here might know how to get that code to be more responsive to different sampling rates... (you could change your sampling rate to 44100 in the meantime though, Raphaël) best, P
Isn't this the way to do it? x->x_rate = sys_getsr();
On Sun, May 3, 2015 at 6:32 AM, Peter P. peterparker@fastmail.com wrote:
- Raphaël Ilias phae.ilias@gmail.com [2015-05-02 16:36]:
Hello,
I was testing the [bandpass] and [notch] object's from "ggee" library, which compute coefficients values for vanilla's [biquad~] and discovered that the center frequency wasn't the one expected, but was shifted something like 10%.
After a few measurement I found that the real center frequency was around 1.08841 upwards the ferquency value set to [bandpass] or to [notch] inlets...
...and I later realized that 48000/44100 = 1.088435... and that on my computer, pd is working at 48000 Hz. So, apparently these objects are calculating the coefficients with an supposed samplerate of 44100 Hz.
You are right. I just looked at the source file for one of these objects, and it contains a line
x->x_rate = 44100.0;
So apparently the sample rate for it is hard-coded. I don't know ir Günther is actively monitoring the pd-list, but perhaps someone else here might know how to get that code to be more responsive to different sampling rates... (you could change your sampling rate to 44100 in the meantime though, Raphaël) best, P
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi !
Thank you Peter for checking the source code !
Yes I could change my sampling rate. But, well, I think it's better if pd is able work at different sampling rates, and many standards now prefer 48KHz to 44.1 (i.e. digital video recorders).
For now, i'll just make a trick/abstraction that gets the working sampling rate with [samplerate~] and corrects the frequency parameter by applying a coefficient (* 44100 / SR)...
However, IMHO, since frequency representation is related to the time and not the sampling rate, I think this should be corrected in the object itself, maybe as Alexandros suggested. But I don't have the skills to do that myself... hope Günther will read this.
have a nice day,
Raphaël
2015-05-03 5:32 GMT+02:00 Peter P. peterparker@fastmail.com:
- Raphaël Ilias phae.ilias@gmail.com [2015-05-02 16:36]:
Hello,
I was testing the [bandpass] and [notch] object's from "ggee" library, which compute coefficients values for vanilla's [biquad~] and discovered that the center frequency wasn't the one expected, but was shifted something like 10%.
After a few measurement I found that the real center frequency was around 1.08841 upwards the ferquency value set to [bandpass] or to [notch] inlets...
...and I later realized that 48000/44100 = 1.088435... and that on my computer, pd is working at 48000 Hz. So, apparently these objects are calculating the coefficients with an supposed samplerate of 44100 Hz.
You are right. I just looked at the source file for one of these objects, and it contains a line
x->x_rate = 44100.0;
So apparently the sample rate for it is hard-coded. I don't know ir Günther is actively monitoring the pd-list, but perhaps someone else here might know how to get that code to be more responsive to different sampling rates... (you could change your sampling rate to 44100 in the meantime though, Raphaël) best, P
On Sun, May 3, 2015 at 2:58 PM, Raphaël Ilias phae.ilias@gmail.com wrote:
However, IMHO, since frequency representation is related to the time and not the sampling rate, I think this should be corrected in the object itself, maybe as Alexandros suggested. But I don't have the skills to do that myself... hope Günther will read this.
I've written some externals and used this and it works fine. If you just change this line of code and compile the object, it should work, I guess...
On 2015-05-03 03:11 PM, Alexandros Drymonitis wrote:
On Sun, May 3, 2015 at 2:58 PM, Raphaël Ilias <phae.ilias@gmail.com mailto:phae.ilias@gmail.com> wrote:
However, IMHO, since frequency representation is related to the time and not the sampling rate, I think this should be corrected in the object itself, maybe as Alexandros suggested. But I don't have the skills to do that myself... hope Günther will read this.I've written some externals and used this and it works fine. If you just change this line of code and compile the object, it should work, I guess...
It might be better to replace the 44100.0 by the proper function here like: x->x_rate = sys_getsr();
But more objects in ggee have the same issue. Maybe the author had a good reason for this...
A patch to fix them all is easy to make and add to sourceforge.
Fred Jan
On 2015-05-03 15:58, Fred Jan Kraan wrote:
On 2015-05-03 03:11 PM, Alexandros Drymonitis wrote:
On Sun, May 3, 2015 at 2:58 PM, Raphaël Ilias <phae.ilias@gmail.com mailto:phae.ilias@gmail.com> wrote:
However, IMHO, since frequency representation is related to the time and not the sampling rate, I think this should be corrected in the object itself, maybe as Alexandros suggested. But I don't have the skills to do that myself... hope Günther will read this.I've written some externals and used this and it works fine. If you just change this line of code and compile the object, it should work, I guess...
It might be better to replace the 44100.0 by the proper function here like: x->x_rate = sys_getsr();
But more objects in ggee have the same issue. Maybe the author had a good reason for this...
A patch to fix them all is easy to make and add to sourceforge.
thanks for your efforts.
have you tested this in a subpatch that uses re-sampling (and/or overlap)?
afaik, the *proper* way to get the samplerate for oscillators is to use
the s_sr member of the signal-struct: "sp[0]->s_sr"
at least this is how it is done in all Pd-internal oscillators, and i
guess it would make sense to have this behaviour be consistent across
all oscillators (whether internal or external).
fgams IOhannes
Hi IOhannes,
On 2015-05-03 15:58, Fred Jan Kraan wrote:
A patch to fix them all is easy to make and add to sourceforge.
thanks for your efforts.
have you tested this in a subpatch that uses re-sampling (and/or overlap)?
afaik, the *proper* way to get the samplerate for oscillators is to use the
s_srmember of the signal-struct: "sp[0]->s_sr" at least this is how it is done in all Pd-internal oscillators, and i guess it would make sense to have this behaviour be consistent across all oscillators (whether internal or external).
Thanks for the response. I hoped the patch would be an improvement to the current situation, but apparently there is more room for improvement. It will take some more time to understand, include and test these.
fgams IOhannes
Greetings,
Fred Jan
Hi !
I don't have the skills (and honestly the time for now) to change source code and compile it. However, I made a test patch that demonstrates the behaviour of [notch] when pd dsp is computed at 48000Hz, and the trick I use to correct it.
Cheers,
Raphaël
- Alexandros Drymonitis adrcki@gmail.com [2015-05-03 09:11]:
On Sun, May 3, 2015 at 2:58 PM, Raphaël Ilias phae.ilias@gmail.com wrote:
However, IMHO, since frequency representation is related to the time and not the sampling rate, I think this should be corrected in the object itself, maybe as Alexandros suggested. But I don't have the skills to do that myself... hope Günther will read this.
I've written some externals and used this and it works fine. If you just change this line of code and compile the object, it should work, I guess...
Yes, Raphaël, try to do that. And report back if it works ;)
-
Alexandros Drymonitis -
Fred Jan Kraan -
IOhannes m zmoelnig -
Peter P. -
Raphaël Ilias