I’m wanting to create an unmistakable way of alerting myself when my output levels are too hot.
I’m thinking maybe of using a couple of shape widgets, both of which will be the full size and shape of the uppermost panel in my Global Rackspace, one of them behind all the other widgets and coloured green, and the other one in front of all the widgets and coloured red.
I’ll define two loudness thresholds; when my short-term output level is below the lower of the two (say -24LUFS), both shape widgets will be invisible (and the colour of the panel itself will show through), letting me know that my output level is quiet or silent. When my level is between the two thresholds (say, between -24LUFS and -12LUFS), the green widget will become visible, letting me know that I’m sending output at a decent loudness level. And then when the output level is above the higher threshold (louder than -12LUFS, say), the red widget will become visible, blocking out eveything else on the panel, letting me know that I’m too loud. Maybe to get real fancy I’ll play with the transparency of the widgets so as to blend from one colour into the next.
I would love some hints as to the best way to go about this. I’m thinking I’ll need to find a loudness plugin that exposes the short-term loudness as a parameter, and then connect that parameter to a widget; then I can implement the “On WidgetValueChanged” callback for that widget, and depending on the value, manipulate the visibilities of the two enormous shape widgets.
To start with, I’ve been playing with just using the built-in plugins; I’ve mapped a meter widget to one of the “Output Level” parameters of my “Audio Out” block, but it doesn’t seem to trigger any WidgetValueChanged events. (In the end I don’t think this would be wise anyway, because such events could potentially be coming as fast as the sample rate, whereas I really only need to check the value a few times per second.)
The internal meter-widget is of some “special kind” and it’s not suitable for the task you want it to do… as you already have discovered.
You could use the midiAudioToCC plugin from the “piz-midi” collection which can be downloaded for free… Piz MIDI Utilities: Archived Download Links | Paul Cecchetti Music
midiAudioToCC will convert an audio level to a CC value which you then can analyze or use at will.
To avoid too much flickering of your alert-widgets (with each peak above a threshold), you should probably use an additional time base, to either “collect” multiple clipping events over a given time or freeze the clipping state for a certain amount of time, so that even a short peak still stays visible for a moment.
Also, I just found out about the existence of ReaJS, which (if I understand what I’m reading) makes it possible to run JSFX (JesuSonic) plugins in a VST host. The JSFX language is a powerful and easy way of creating both audio and MIDI plugins within Reaper, and if this can run in GP it’s a game-changer!
(Before Cockos developed Reaper, they were working on a realtime audio processing platform with plugins written in an early prototype of the JSFX language.)
(I already have way too many GP crashes as a result of my own GPscript bugs, and adding JSFX bugs to the mix might be unwise, but I’m tempted…)
The ReaJS plugin works well, but the catch is that development has stopped (last version 2016). There is also ysfx: this is a open source version. Works quite well and is actively maintained. Main difference is ReaJS is a vst2 plugin, ysfx is a vst3 plugin (as far as I can see, they use Juce). I suspect that vst3 doesn’t support sending most of the real-time midi messages like spp, song start, song stop, etc.