posted 23 October 2000 11:06            

butterworth.kym

In my experimenting, I decided to try to implement a 4-pole Butterworth LPF (see attachement).

I have to keep remembering that the 56K is an integer DSP (although a very good one indeed! - but I have been spoiled by the SHARC). Hence two problems/questions arise on how to handle some situations that have arisen:

1. Since all Constant modules require that their values lie between 0 and 1, I have been forced to perform a large number of redundant computations in gain settings. This is because some of these gain constants or their constituent values can be larger than one. Is there a better way to distribute this kind of math to all the gain values without repeated calculation?

2. Special functions, like normCos and normSin, must be computed by wavetable lookup. I was informed by the compiler that although normTan can be computed by Smalltalk, it cannot be computed by Capy. Hence, I compute the normTan by means of a ratio normSin/normCos (actually I compute the cotangent = normCos / normSin). Since this is based on table lookup, roundoff errors are significant in the computed value of the cotangent near the band edges, especially when the Butterworth filter cutoff frequency is a very small fraction of the sample frequency. The result is rather poor alignment of my produced cutoff frequency with respect to what was requested. Any suggestions on how to handle functions that have steep slope here?

Cheers,

posted 24 October 2000 07:29            

Thanks for your reply...

I tried two variations on my Butterworths after writing the posting earlier today.

First, I tried using the edge cases you mentioned by means of Taylor expansions for the filter coefficients near frequency = 0. Bad Idea!!! The poles and zeros get so tightly clustered near the unit circle that the darn thing wouldn't even produce a sound! Talk about roundoff errors!

Second, I tried generating some WaveTables to perform the coefficient computations. I hoped that these would offload the DSP's a bit, and perhaps provide better accuracy since they are computed offline using double-precision arithmetic. Well... the MultiplyingWaveTable Sound uses a lot of memory (4096 entries for each of 3 tables) and apparently uses a lot of DSP compute time. The result worked no worse than before with direct calculation, but the DSP loading went through the roof! Finally, it provided no improvement at the edge cases. This is probably again because with only 4096 elements and no interpolation, the roundoff/truncation errors are too coarse.

What I did find, is a way to use heterodyning to send my low frequencies through one or more Reson filters tuned to the mid-band (sampleRate / 4) and then heterodyne back to DC, building a LPF. This worked pretty well, and I can build very narrow filters this way.

But after all the effort today, I compared my results to those of the Kyma LPF/HPF and I find that the Kyma filters without feedback are incredibly good! If it isn't a trade secret I would sure love to know more about them. If it is a secret, then well done! I can't beat them with high-level Kyma code. Anything that could match their passbands would surely exhaust the Capy DSP's when done solely in high-level Kyma. Besides, the Kyma filters have almost negligible compute overhead on the Capy!

So thanks, and a better tangent routine probably won't help, since you use table lookup anyway. The table spacing gets too coarse in the high slope regions no matter how many entries you use!

Cheers,