Ploki

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

rms-math

 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.

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.


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.

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

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.

I know of average~ but its quite a CPU hog. Wanted to go through a CPU friendlier path.

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:

you could use the mathematically equivalent comparison

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):

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.

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.

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:

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)

Please file a report; that sounds very suspect.  

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)


RMS math?