non MSP IIR filter

    Jan 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?

    • Jan 22 2013 | 10:20 am
      Hi Javier What is the reason for needing to avoid the signal domain? The low freq control data? Brendan
    • Jan 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.
    • Jan 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
    • Jan 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:
    • Jan 23 2013 | 11:50 am
      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
    • Jan 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.
    • Jan 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, vexpr, and zl.sum. Could be interesting to use a window function with that.
    • Jan 29 2013 | 4:08 pm
      that's great.. I think I can get away with regular objects. Thanks everyone!
    • Dec 05 2014 | 9:58 pm
      I just uploaded C code I wrote 10 years ago that does IIR processing. (Sorry I didn't do this sooner. I was wrapped in a PHP object and couldn't get out.) It most certainly needs updating and I'll get to that as soon as I can. It's at: