non MSP IIR filter

Jan 22, 2013 at 12:18am

non MSP IIR filter

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!

#66171
Jan 22, 2013 at 10:20am

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

#238181
Jan 22, 2013 at 11:54am

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.

#238182
Jan 22, 2013 at 12:37pm

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

#238183
Jan 22, 2013 at 5:20pm

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

#238184
Jan 23, 2013 at 11:50am

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

#238185
Jan 23, 2013 at 8:45pm

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. –
#238186
Jan 23, 2013 at 9:02pm

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.

#238187
Jan 29, 2013 at 4:08pm

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

#238188

You must be logged in to reply to this topic.