RMS math?

    May 27 2013 | 10:05 pm
    Any way of doing RMS after peakamp~ from numbers since it takes less resources?

    • May 27 2013 | 11:12 pm
      The peakamp~ object reports the peak amplitude during a period of time, not the RMS amplitude. Those are two different beasts, and you can't reconstruct RMS from a peak amplitude value. You could take the mean of several successive peak values, but that still would not tell you anything about RMS. For RMS amplitude of a signal, see the average~ object.
    • May 27 2013 | 11:15 pm
      first root, then mean (of a number of samples), then suqre, just as the name suggests, but using the output of peakamp~ you will get a totally different results fromw hat you exspect. snapshot~ would be a much better choice.
      if saving CPU is your aim, i would recommend against using numbers. measuring power by rms works great when just downsampling the process *8 or *16 using poly~.
    • May 27 2013 | 11:26 pm
      ah. I'll try the downsampling path then.
      I know of average~ but its quite a CPU hog. Wanted to go through a CPU friendlier path.
      thank you both for answers
    • May 28 2013 | 9:15 am
      first root, then mean (of a number of samples), then suqre, just as the name suggests
      As the name suggests, but wrong order: first square (to get positive values), then take the mean of the squares, then take the square root (to get back to the original "order of magnitude").
      Also, if you are concerned about CPU, you may be able to make comparisons with the squared value, saving the (expensive) calculation of the square root. For instance, instead of something like:
      if rms(something) > 2
      you could use the mathematically equivalent comparison
      if mean-of-squares(something) > 4
      Furthermore, if you are taking the mean of a constant number of values, it is still more computationally efficient to use something like (as an arbitrary example, assuming your original rms was of 32 values):
      if sum-of-squares(something) > 128
      Mind you, processing a message through a single Max patch cord probably eats more CPU than a single divide (what we avoided with the last 'optimization'), and not that much more than taking a square root. Just so you have your priorities sorted.
    • May 28 2013 | 9:32 am
      I just switched from 1440*900 HiDPI to 1440*900 nonHiDPI and CPU usage dropped from 50% (out of 800%) to 13% for the same patcher.
      I only have one (!) number object on the screen, and one fpic doing nothing.
      I shouldn't have to care about CPU on a Quadcore i7 for 8 peakamp~ and 8 average~ objects.
      I smell bugs
    • May 29 2013 | 8:59 pm
      Please file a report; that sounds very suspect.
      If you are looking for an efficient way to capture the amplitude envelope, I like slide~.
      My preferred envelope follower is something like this:
      average~ 100 absolute | *~ 2.25 | slide~ 200 2500
      Tweak the numbers as need be for material, but it captures the transient attacks well while smoothing out the decay. (It's more of a VU sort of curve)