VU Meter (JS plug for Reaper, vector GUI, low CPU)

[Chris-S]

The plugin is now attached (first post).

Some details:

The needle simulation is running at 10% of the sampling rate.

Damping factor is choosen so that the "overshooting" is minimal (0.1 db or so).

Integration time should be 300 ms with default settings but you can change
the inertia-momentum of the needle.

[Chris-S]

New version (1.1) is fully resizable and has a circular design.

Preview and 0 dBvu (-18 dBfs sinus) test:


Download-Link updated (first post).

Video:
https://youtu.be/LmhN8I0hZL0

[JCJR]

Hi Chris

That looks good. Will try find time to test the meter. Been busy with the prosaic task of rebuilding a rotten porch.

One thing I've wondered about is "animation visual smoothing" for this kind of display. Have noticed in the past that "fine detail" motion updated on-screen the "standard" 30 or 60 times per second can look gappy or flickery compared to watching a real-world meter. Maybe it somewhat depends on the video monitor latency. Maybe a low-latency fancy gaming monitor would "look more realistic" to the eye than an ordinary "fairly slow" LCD display, when fast video monitors and ordinary average-speed monitors are driven by the identical code? I never paid extra money for fast monitors. All my monitors and laptop screens are however fast is the average "affordable" video latency-- Phosphor decay when a pixel is turned off, and whatever "ordinary quality" transistor switch and LCD turn-on delay happens when a pixel is turned on.

Watching fast-motion on video recordings, at the same 30 or 60 frames-per-second, can look more realistic. If one steps thru the individual video frames of fast action (like a fast-moving VU indicator recorded with a video camera) the needle can look motion-blurred on any individual frame. But the overall impression to the eye of the animated motion-blurred frames displayed in real-time, looks smoother and more realistic than a program drawing "crisp" images at 30 or 60 frames per second.

Sometimes I've done crude attempts at video time-smoothing across frames for meter-type displays but never spent a lot of time on it.

One thing that might not eat too much cpu rendering time, one could remember one or more of the previous-frame VU values. Maybe just 1 previous value, or maybe a few.

For instance, on each @GFX draw cycle, if remembering history of the previous 4 frames-- On an offscreen buffer, blit the meter background. Then draw an 80 percent transparent black line for the needle value of VUValue[-4], draw a 60 percent transparent black line for the needle value of VUValue[-3], draw 40 percent transparent for VUValue[-2] and 20 percent transparent for VUValue[-1]. Finally draw the current VUValue[0] at 0 percent transparent black, then blit the completed composite offscreen image to the screen.

Maybe something like that would look smoother? Dunno. Might try it one day.

Perhaps with real fast meter motion that would still look bad. Perhaps real fast meter motion would need some way of drawing a solid arc of "variable transparency" from one needle value to the next?

[Chris-S]

The @gfx is running only at 25 frames per second or so. Of course more is better. Ideal would be a frame rate which is in sync with the hardware rate (typically 60/sec).

[camsr]

ReaJS is limited to 25hz graphics rate? That's the same as Reaktor, it's kinda disappointing too because it's quite slow.

[JCJR]

Thanks Chris-S

It ought to be easy to write a js screen refresh rate tester, but it would only give the refresh rate of whatever computer the tester is run on. I hadn't thought about the jsfx refresh rate. Googling, didn't find anything authoritative. One comment from Tale claimed "about 30 fps" which is in the same ballpark you quote.

I don't use embedded video with Reaper. Some comments briefly scanned, apparently Reaper can sync its refresh rate to a video's native rate. I also saw a comment that the refresh rate of the master meters can be adjusted, but dunno if there is a Reaper setting for setting global screen refresh rate. It is a deep program and I've not closely studied it.

In years past, when computers were not so fast and it was not uncommon to find computers where the video card/drivers could heavily compete against audio and midi timing, causing not uncommon resource contention with audio dropouts and messed-up MIDI timing--

When I was writing on thangs like multitrack mixer panels and track displays with numerous per-track mini-meters, would throttle the screen update rates to give the audio and midi a better chance at good playback. With each multitrack window maintained typical "object oriented" my timer code would fire window updates slower than the typical 60 fps refresh rate. As best I recall, sometimes as slow as 10 updates per second. The timer code would set a flag to invalidate the window at whatever was the desired refresh rate. The flags would be read by the main process event handler, which would invalidate the windows. Then the OS + Framework would eventually get around to calling each window's draw code on invalidated window regions.

If coding for max efficiency would try to keep up with only the screen pixels which might have changed. But that could get complicated enough that often it was better just to redraw the entire window as long as it was "fast enough" to minimize programmer labor and associated programmer brain damage. Redraw to offscreen buffers then blit to screen to minimize flickering.

So it isn't surprising that Reaper would throttle screeen updates. Computers are so much faster nowadays, but I guess a computer will never be "as fast as we want" and many customers have fairly slow computers even today.

[Chris-S]

One comment from Tale claimed "about 30 fps"

Yes this number is said in the official JSFX doc. But concerning to my own measurement it's even lower (on Win-7).

[Chris-S]

Yes I know that the modern LUFS stuff is way more sophisticated.

But at least the LUFS meter I checked (youlean) is also showing the volume drop for triangle waves
(1.8 dB, vs. 2.1 dB drop for VU meters).

Didn't expected this.

Interesting question is: Is the human ear also integrating and perceiving triangle waves quieter than sinus waves? I for myself hear a quieter base harmonic but in sum I would assess both waves having the same loudness.

[JCJR]

Any time-integrating meter, even average reading meter ought to measure sine and triangle of equal peak amplitudes, at different average or RMS levels.

Even a peak meter might show different levels, depending on the speed of the peak meter decay. If the peak meter decay is fairly fast, then the triangle would give the decay "better opportunity to decay between peaks" because the triangle falls off from the peaks faster than the sine. Perhaps most likely if the decay is the sort that "decays toward current instantaneous value" rather than "decays toward zero".

I've seen some peak envelope follower code that has instant attack if the current sample is greater than the current envelope value but otherwise decays toward zero. Another way to do it is instant attack if the sample is greater than the current envelope value but otherwise decay toward the current sample value.

You can see both approaches in different old analog compressor designs.
****
<speculation and guessing>
The ear isn't very sensitive to amplitude differences. But up to about 2 kHz to 4 kHz, the same amplitude at a higher pitch tends to sound louder. Above about 4 kHz, the same amplitude at a higher pitch tends to sound quieter.

So for instance a triangle wave at 40 Hz ought to sound louder than the same-RMS-amplitude 40 Hz sine wave, because the triangle's sine level harmonic 1 at 40 Hz is a little less than the pure sine wave, but there are a few higher-harmonics added to make up the difference, and the ear should be more sensitive to those added higher harmonics.

So far as I know the ear tends to judge amplitude by the averages, somewhat. But comparing equal-peak 40 Hz triangle wave vs sine wave, the ear would hear lower average level in the triangle, but the ear would also be more sensitive to the higher harmonics in the triangle wave. So the better sensitivity to the triangle's higher harmonics might "somewhat compensate" for the lower average level in the triangle wave. Especially because the ear is not very sensitive to amplitude differences but is very sensitive to frequency differences,

The perceived difference might vary by the frequency of the test tone pair. At very high frequencies the triangle and sine might sound identical because the triangle's harmonics are beyond the hearing limit or in the range where the ear becomes rather insensitive. In which case the equal-peak triangle might sound quite a bit quieter than the sine.
****
"Peak meter decay toward zero" would probably read exactly the same for any waveshape peaking exactly the same. A 1 percent pulse peaking at 1.0 reading identical to a sine wave peaking at 1.0.

A fairly fast decay "decay toward current sample" wouldn't read the 1 percent pulse the same as the sine wave, because the 1 percent pulse "average sample value" is lower and so the decay ought to fall to a lower level in-between the peaks.

Hmm. I had preferred the "peak decay toward current sample" in compressor code, but maybe "peak decay toward zero" is better for peak meters, because it would tend to measure peaks "nearly the same" at any particular frequency, regardless of the wave shape?

[Chris-S]

Some peak meters also have a hold time for catching the peaks better....

[PearlOn3]

AUTO-ADMIN: Non-MP3, WAV, OGG, SoundCloud, YouTube, Vimeo, Twitter and Facebook links in this post have been protected automatically. Once the member reaches 5 posts the links will function as normal.

Thanks Chris, I really love this meter. It has been my go-to for years now. Over time I have made several changes and recently made it public as a modification.
If you like, take a look:
https://forum.cockos.com/showthread.php ... ost2522572 (https://forum.cockos.com/showthread.php?p=2522572#post2522572)

Greetings,
Zeno