Forums > MaxMSP

non MSP IIR filter

January 22, 2013 | 12:18 am

Hi there,

I’m interested in building an IIR filter for control signals (e.g. sensor data at 50Hz) that doesn’t use signal objects (e.g. sig~). Does anybody have any experience with building IIR filters in javascript for max?

Thanks!


January 22, 2013 | 10:20 am

Hi Javier
What is the reason for needing to avoid the signal domain?
The low freq control data?
Brendan


January 22, 2013 | 11:54 am

Hi Brendan.. yes, i don’t want to upsample and downsample just to implement the IIR filter… especially because I might need to run this for 20 or more signals simultaneously.


January 22, 2013 | 12:37 pm

Did you try posting under Gen? No doubt you’re not insistent about JS? Sadly I’m fluent in neither, and any attempt at a lpf in Max I make will just duplicate your own.

Best
Brendan


January 22, 2013 | 5:20 pm

I’d strongly recommend keeping this in signal domain if you want to do this via normal IIR filter. MSP has some pretty efficient filters, such as onepole~, and IIR filters are a pain to implement correctly, since you have to be aware of things like denormal numbers.

If it’s sensor data, however, I’d use slide~ (there’s slide in control rate as well, but you’d need to be feeding it at a steady rate) or rampsmooth~, or if it’s coming in at control rate, use line or line~ to smooth it out. Slide~ is almost obscenely efficient, btw.

If something needs very regular processing (e.g. it’s calculated > 20 times a second), I recommend doing it in signal domain. It’s pretty efficient, and if you want to save CPU on these types of control processes, you can always downsample with poly~. (I routinely downsample my LFOs by a factor of 16.)

If you’re scheduling a bunch of events in the controller thread, the scheduler gets unhappy, and then you lose timing precision (not so with signal domain!) –which your IIR coefficients are dependent upon! You also don’t really have an accurate sense of how much CPU the scheduler itself is using, so there can be problems with spikes.

In general, my rule of thumb is don’t use control-rate to do things more efficiently than signal rate. It blocks up your scheduler thread for more important things, and usually isn’t worth the trouble.

Either Line or slide would work if you really want to avoid signal rate. (interpolation = lowpass filtering)

You can find formulas for various biquad filters here:

http://www.musicdsp.org/files/Audio-EQ-Cookbook.txt


January 23, 2013 | 11:50 am

Javier,

MnM (part of IRCAM’s FTM) has a 1st order IIR filter ( y[n] = alpha * x[n] + (1 – alpha) * y[n-1] )
It’s called [mnm.alphafilter]

Lots of goodies in the mnm package for massaging sensor data streams.

– Miguel


January 23, 2013 | 8:45 pm

What’s wrong with regular objects? It’s pretty easy to implement, I doubt denormal is ever going to be a problem there.

– Pasted Max Patch, click to expand. –

January 23, 2013 | 9:02 pm

Looks like the denormal thing doesn’t matter w/ Max. Good to know. (is there anything internal to Max that does that?)

I personally prefer slide, since you get the benefits of asymmetry in attack/decay if needed. Really depends on what your signal looks like. For things that are similar to a percussive attack, having a fast attack + long decay often works pretty well.

Bit of a wild hair here, but you could also pretty easily implement an FIR filter via zl.stream, vexpr, and zl.sum. Could be interesting to use a window function with that.


January 29, 2013 | 4:08 pm

that’s great.. I think I can get away with regular objects. Thanks everyone!


Viewing 9 posts - 1 through 9 (of 9 total)