On Apr 10, 2012, at 10:14 AM, Cyrille Henry wrote:
Le 10/04/2012 16:05, Hans-Christoph Steiner a écrit :
On Apr 10, 2012, at 1:06 AM, IOhannes m zmölnig wrote:
On 04/09/12 23:59, Hans-Christoph Steiner wrote:
It understands the global sample rate, but not yet the sample rate set with [block~].
while i haven't looked at the object yet (though it sounds very useful), i would like to suggest adding a message that forces filter coefficients to be calculated for a certain samplerate.
e.g. [samplerate 8000(
which would override the default (which is to take the subpatches samplerate (as set by [block~])
Why not just make it respect the [block~] settings?
i think making it to respect [block~] setting is very important to this object, but having possibility to set an other samplerate would allow other utilisation : it could then be also use to compute filter coefficient for pix_biquad by example.
I agree entirely, but I have run out of time to work on this for a long while. Patches and forks are welcome, and I'll try to make the time to integrate people's work into this one. There is a lot this object could do, including having a logarithmic scale for frequency (its linear now).
Another idea is to make it into a library that includes all of the biquad calc objects from ggee, then the math functions written in C could be used for the GUI calcs too, making it faster. They could be written as signal objects also, so we'd have [bandpass] and [bandpass~], etc. Then it would need to include a version of [biquad~] that had 5 signal inlets for the 5 coefficients at signal rate.
.hc
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White