VU Meters

what’s the best way of handling vu meters in say a VST with JUCE. I’ve got it doing, but it has a huge impact on the redraw in Tracktion. clues, ideas… suggestions? :idea:

Generally you’d do it in the idle() method of the editor - this is called repeatedly by the host so you can do things like update vu meters, draw waveform displays etc.

I haven’t looked at Jules’ Audio Plugin stuff in a while though, so I don’t know if it actually gives you access to the idle calls.

  • Niall.

We’ll, I’ve taken the template and added updated it specificly for VST. So it’s got the effeditoridle call… but it still appears to be not freaquent enough for a responsive VU meter. maybe I’m drawing the meters incorrectly. :shock:

Well, with the idle() method, you are limited to how frequently the host calls it, but in my experience Tracktion’s one of the more frequent hosts out there. How are you drawing the meters? Could it be something to do with the way you’re supplying them with the amplitude data? I’d have thought you’d have to be doing something pretty drastic for the drawing of the meters to have a noticeable effect on their responsiveness…

  • Niall.

well, I have a little meter component, that receives the amplitudes, then performs a simple fillrect adjusted to the height of the amplitude. The problem is that the idle call doesn’t seem fast enough… so the meters look really slow and unresponsive.

however, as a test (cos I know you are not s’posed to do this), I made it update from process every 1470 samples @ 44100 (30fps) and it was very responsive, but ate into the cpu.

so my question is how do you get responsive meters that don’t eat cpu? cos I just can’t figure it out for whatever reason.

current JuceAudioPlugin does not handle EffEditIlde, I think JUCE message loop runs in a different thread than the host thread so you can just use JUCE timers to do what you want

Yeah, use Juce timers rather than effIdle, and make sure you repaint only the bits of the meter that have actually changed.