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