1) The current Plugin Demo uses a timerCallback() which regularly checks the processor variables and updates the GUI:
JuceDemoPluginAudioProcessor* ourProcessor = getProcessor();
AudioPlayHead::CurrentPositionInfo newPos (ourProcessor->lastPosInfo);
if (lastDisplayedPosition != newPos)
gainSlider->setValue (ourProcessor->gain, false);
delaySlider->setValue (ourProcessor->delay, false);
2) The previous Plugin Demo used a changeListenerCallback:
void JuceDemoPluginAudioProcessorEditor::changeListenerCallback (void* source)
// this is the filter telling us that it's changed, so we'll update our
// display of the time, midi message, etc.
notified from the processor's setParameter function:
void JuceDemoPluginAudioProcessor::setParameter (int index, float newValue)
//All parameters should have values in the [0,1] range! This is a standard!
if (index == 0)
if (gain != newValue)
gain = newValue;
// if this is changing the gain, broadcast a change message which
// our editor will pick up.
I understand that 1) would be the most appropriate way to update the graphical representation of variables which are written during the processor's processBlock (e.g. VU meter) (you don't want to update the GUI with the frame rate)
I understand that 2) should be more efficient for a parameter which is only used as an input to the processor's processBlock (since it will probably be updated less often than the timercallback). However for an automated parameter I guess the host is probably calling setParameter at the frame rate too right?
Am I missing anything else under the hood? Do you know other interesting and safe ways to do this?