How to Calculate RMS, K-Metering etc
-
How's it going Hise crew?!
Does anybody know how to go about calculate RMS and potentially K-Meter levels in Hise from:
Engine.getMasterPeakLevel()
I've been searching around the web trying to find the maths but nothing so far.
If you've got any links, or info in general don't hold back :smiling_face_with_sunglasses:
Hope everybody's good either way!
-
@leec You'll get nothing usable as a trustable value out from this function. This is just for display purposes.
The reason is fairly simple, you need a timer to call it. meaning that you will get the level once every X milliseconds (usually 30-50ms).30ms at 48Khz => 48x30 (or 48000x0.03) = 1440 samples
That's a lot of missed samples in between to compute any level value! (well, since the peakLevel is already damped, that is not entirely true, but you get the point)For this, you need a DSP, record all samples, and make the computation you need depending on the norm you want.
Any computation usually requires a timing window, and for some (like the K system or any weighted program) one or several custom made filters. If windowing a time frame as you record samples is not a big deal, making DSP filters that stick to the recommendation is another thing...
I just scratched the surface of it, and understanding the tech part of the recommendations is already somethingI want to add that
Engine.getMasterPeakLevel
is not a good term in Hise, as many people take it for granted. It is not a peak level, and even less a true peak... (essentially due to timer things) It in fact uses the peak value internally, but since you'll use a timer, you have no idea about what is the value at a precise time. -
Great explanation as always @ustk.
I appreciate that it will still lead to some level of measurement inaccuracy, but is there a way to reduce the lower level of the timer in HISE to ultimately get more samples?
Reduce it lower than the 30ms limit that is?
-
@leec Reducing the timer is not a viable solution. Christoph said from the beginning that we shouldn't go below 20ms or something in that ballpark, so the thread is not cluttered.
For any drawing purposes, 30ms is already more than 33fps.
Even if you could go as down as 1ms, it's still 47 missed samples out of 48... Definitely, the timer is only good for display purposes, you will never get any usable value out of it. -
@ustk Fair enough.
I probably should have mentioned that I'm attempting to build a vintage style VU meter capable of various output measurements.
I guess even if there was a "pure" way to get all the samples and make said calculations, the accuracy of the display of these values (in a png strip for example) would always be skewed, due to the fact that a timer would have to be used.
If I've understood correctly that is! :grinning_face_with_big_eyes:
-
Makes me wonder how the likes of Waves and Klanghelm achieved measurements in their VU meters.
Obviously, they weren't built using HISE, but I'm now curious as to whether they too inherit similar inaccuracies when it comes to displaying these calculations in a filmstrip. -
@leec said in How to Calculate RMS, K-Metering etc:
Makes me wonder how the likes of Waves and Klanghelm achieved measurements in their VU meters.
C++
-
@leec If you just need to display a filmstrip or draw something, you are right in saying that the timer will always give approximations, and it is not a big deal. If you don't need to display a value in terms of numbers (like the overall peak, the true peak, or the peak over a period of time just to name a few) then the approximations are not real issues.
However, you are talking about VU meters. And a VU meter is not a peak, meaning you need an accurate time frame anyway to compute the slope time (rising time) of the needle, which is different when going upward or downward.
I'm certain that the brand you mentioned use internal DSPs -
Appreciate the clarity @ustk.
Very useful! -
Terms are important. People often think they have a VU meter or a peak meter on their interface. But it is not true.
Hise offers none of them in terms of value. but it is good enough for displaying the level. However, there is also something here... The falling of the Hise "peak" meter is linear, but you generally want a log scale. So a conversion has to be made here too. Unless you want a linear display of course...That brings me to the point where I will try to make a pull request tonight that makes the Hise meter logarithmic. (the peakLevel value stays unchanged as it is not related, it is just the visual falling of the meter. But maybe people like it as it is, I personally don't like linear meters... So Christoph might not accept it ;)