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