## RMS math?

May 27, 2013 at 3:05pm

# RMS math?

Any way of doing RMS after peakamp~ from numbers since it takes less resources?

#250837
May 27, 2013 at 4:12pm

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.

#250841
May 27, 2013 at 4:15pm

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~.

-110

#250842
May 27, 2013 at 4:26pm

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.

#250844
May 28, 2013 at 2:15am

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.

#250910
May 28, 2013 at 2:32am

Wow.

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

#250911
May 29, 2013 at 1:59pm

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)

#251135

You must be logged in to reply to this topic.