I've noticed this problem anytime I try to use aÂ VUmeter (analog or LED). When applying a sinusoid from the internal oscillator or from an audio file, instead of showing a constant value, the VUmeter keeps going up and down, like it was receiving some kind of noise.
I've tested the XYPadsMeters example and got the same results.
It's interesting because the Meters in the RackAFX IDE are working like they should.
It seems to happen only when the info to be displayed come from the audio frame. When I send a constant value , or the gr value from the book dynamics project, the meters work fine.
My OS is windows 10/64
Would this have anything to do with not having either a 'grab max peak' functionality or not applying meter ballistics with a release slow enough to represent the incoming signal more accurately? I would assume that a sinusoid at 44.1k would have a lot of data points to pick from when it shows the meterÂ
Would this have anything to do with not having either a 'grab max peak' functionality or not applying meter ballistics with a release slow enough to represent the incoming signal more accurately? I would assume that a sinusoid at 44.1k would have a lot of data points to pick from when it shows the meterÂ Â Â
I've been playing with the dynamics project a lot to try and get familiar with this plugin framework as a whole, and I also encountered strange behavior with the meters and fast ballistics settings.
Try changing the GUI refresh rate to 16.6 milliseconds (I believe that's 60 fps) and as you hinted at, make sure the release time is actually long enough to decay smoothly. 200-300 ms should do fine; although that is assuming that the time you specify is the time you get, and I don't think that's how Will set up the time constant calculation code. (IE, the time you dial in isn't "how long does it take to go from a to b;" rather it's how long to go from a to 63% of the way to b " . . . If I read the book and code right. I know that's the case with the envelope detector timing code anyway. )
Thanks for the replies, guys.
The problem is that according to Will's book, (tutorial and XYPadsMeter projects) , there is no need to worry about VUmeters at all. It should be just a simple case of creating a control variable of the Vumeter kind, and sending the contents of the audio frame to it. At least that's what is done in the examples.
Oddly, except for these two little apps, there is not a single other example of Vumeters in all of the book projects. The only one I could find was the GR monitor in the dynamics processor project. And in the case of GR, the VU works fine. The problem happens only when we write the contents of the audio frame to the VUmeter control variable.
And again, the VUs in the RackAfx IDE all work fine.
According to this text, this behavior is expected when you use the VSTGUI directly. But RackAFX should handle this for us, like Will says here:
Will said "
... They include a CEnvelopeDetector object inside them which allows you to control how the LEDmeter tracks the signal as linear/log as well as letting you set the attack and release times. The stockCVuMeter only displays the passing value and has no ballistics to it. So, it looks glitchy. If you want asimple challenge, subclass the CVuMeter object to include an envelope detector.!
Lol. Sadly, Will can't do everything for us. 😛 Sometimes his college professor-ness comes out a bit in the books and code; and he encourages us to at least look up how to solve the problem ourselves. (I'm pretty bad at it, but there is a wealth of source code online to read, and after 8 months of reading ASPiK, JUCE, and "learncpp.com", as well as conversations with my developer friends, it does start to make sense. 🙂 )
It shouldn't be too difficult to do what Will describes. Not that I have looked at the GUI stuff yet, because that terrifies me. 🙂 But creating a class that derives from the CVuMeter and adding an envelope detector to it is made easy by the fact that you already have a working implementation of an envelope detector in ASPiK's various demo projects.
You could also just do the envelope detection in the audio processing code and output that value instead, as is done with the dynamics project. (and this is smart in the case of the dynamics project. You technically don't even need to do parameter smoothing, or spend cycles on a second dynamics processor channel if you don't mind full stereo linked channels. With a little refactoring, you can do the envelope detection after the gain computation (including the makeup gain) and rely on the attack and release controls to smooth gain modulation, parameter changes, and the meter output. (Which should look okay as long as your release is long enough and the GUI refresh rate is fast enough. Although adding the envelope detector to the UI itself probably would negate the need for the higher refresh rate. ) )
I don't know how I feel about VSTGUI's way of doing graphics and animation. People seem to prefer vector graphics and using directx or something to do graphics on the GPU, so as not to spend any major CPU time doing the visuals. (this is supposedly one of the big "selling points" of iPlug 2, but I wouldn't know for sure. ) I'm not even sure how to measure the UI's overhead right now. I can't seem to get dll profiling to work (and developer friends suggest it's never going to work by nature of how dlls and visual studio's profiler (probably) work. but I dunno that for a fact either! )
Sorry for the ramble and nested parentheses. 😛 Hope you found some of that interesting or encouraging. I'd be happy to help muddle through the problem solving with you if you'll document your progress here. 🙂
Hi fabhenr, I think those meter's are able to be set up as you wanted from the current CVuMeterEx obect that lives in customcontrols.cpp.
It's very important to add MeterView to the custom-view field of the CVuMeter object in the GUI editor. Otherwise it will be the stock VSTGUI meter and won't have the ballistics that you can set up from initPluginParameters.
Note, I haven't actually tested this on the latest updates but it shouldn't have changed since recently when I had.
Nickolai's response is very good otherwise. If you want to approach your own metering. It's cheap and easy to do the ballistic smoothing from the audio thread. I made my own meters with peak, rms and a hold built in.
RE vector graphics. Probably find once over the learning hurdle that it's an extremely good way to make GUI components.Â
Personally I went overboard making everything vector with +gradients but did start noticing massive performance spikes when using any of controls. These don't usually appear in a DAW's CPU meter but can make a glitchy difference on a busy set.Â
Stepped back to bitmaps for my knobs/skins unfortunately but the problems still remains somewhere within the VSTGUI way of handling graphics. Don't think anything can be improved with ASPiK in that regard but would love to be wrong.
Don't know how it goes on Win10 but for me IPlug2's custom view example is far worse. Basically freezes my DAW as did a recent KVR dev challenge entry - More which was also done in IPlug2. Apparently the graphics don't support Win7 though.
The animation for the GUI is done with a timer that is set for 50 milliseconds and that value is used in the VU meter initialization.Â
You can find this in the bottom of the PluginGUI::open function
You can change the update interval to a lower value, down to about 10 mSec if you like (for comparison, JUCE uses 50 mSec for debug, and 10 mSec for Release versions). I stuck with 50 mSec because this is what the Steinberg engineers used as the default in VSTGUI4.Â
As for my professor-ness, well, that is coming to an end at the end of this year, after which I will be a full-time software engineer at Audio Media Research (I've been consulting with AMR for the last couple of years). While I will still be able to update and maintain RackAFX and ASPiK, I will not be able to divulge anything that would cause a conflict of interest with the projects I am working on.Â
Most Users Ever Online: 152
Currently Browsing this Page:
Guest Posters: 2
Moderators: W Pirkle: 693