# 'Best' way to update the GUI parameters? **URL:** \ **Category:** Audio Plugins\ **Created:** [August 19, 2011, 8:40am UTC](https://forum.juce.com/t/best-way-to-update-the-gui-parameters/7330 "2011-08-19T08:40:53Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![anon78806976](https://avatars.discourse-cdn.com/v4/letter/a/919ad9/32.png) [@anon78806976](https://forum.juce.com/u/anon78806976)\ **Post date:** [August 19, 2011, 8:40am UTC](https://forum.juce.com/t/best-way-to-update-the-gui-parameters/7330/1 "2011-08-19T08:40:53Z")
Hi, 1. The current Plugin Demo uses a timerCallback() which regularly checks the processor variables and updates the GUI: [code]void JuceDemoPluginAudioProcessorEditor::timerCallback() { JuceDemoPluginAudioProcessor\* ourProcessor = getProcessor(); ``` AudioPlayHead::CurrentPositionInfo newPos (ourProcessor->lastPosInfo); if (lastDisplayedPosition != newPos) displayPositionInfo (newPos); gainSlider->setValue (ourProcessor->gain, false); delaySlider->setValue (ourProcessor->delay, false); ``` } [/code] 1. 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. updateParametersFromFilter(); }` notified from the processor’s setParameter function: [code]void JuceDemoPluginAudioProcessor::setParameter (int index, float newValue) { //All parameters should have values in the [0,1] range! This is a standard! jassert(newValue\<=1); jassert(newValue\>=0); ``` if (index == 0) { if (gain != newValue) { gain = newValue; // if this is changing the gain, broadcast a change message which // our editor will pick up. sendChangeMessage (this); } } ``` }[/code] My conclusions: 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](http://www.rawmaterialsoftware.com/viewtopic.php?f=8&t=5781&p=31530&hilit=update+parameters#p31530)) (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? ---
**Author:** ![chkn](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/chkn/32/3862_2.png) [@chkn](https://forum.juce.com/u/chkn)\ **Post date:** [August 19, 2011, 12:25pm UTC](https://forum.juce.com/t/best-way-to-update-the-gui-parameters/7330/2 "2011-08-19T12:25:28Z")
both: use a timer call-back for the vu-meter/automated updates, listeners for irregular updates. ---
**Author:** ![anima](https://avatars.discourse-cdn.com/v4/letter/a/c67d28/32.png) [@anima](https://forum.juce.com/u/anima)\ **Post date:** [August 19, 2011, 3:01pm UTC](https://forum.juce.com/t/best-way-to-update-the-gui-parameters/7330/3 "2011-08-19T15:01:41Z")
Here’s a good article on what to avoid doing in the callback / audio thread. [http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing](http://www.rossbencina.com/code/real-time-audio-programming-101-time-waits-for-nothing) As long as you avoid those pitfalls, anything else should be fine. ---
**Author:** ![matthieu-brucher](https://avatars.discourse-cdn.com/v4/letter/m/a5b964/32.png) [@matthieu-brucher](https://forum.juce.com/u/matthieu-brucher)\ **Post date:** [May 19, 2017, 3:35pm UTC](https://forum.juce.com/t/best-way-to-update-the-gui-parameters/7330/4 "2017-05-19T15:35:45Z")
Are these still the best way to update GUIs from parameters? ---
**Author:** ![jonathonracz](https://avatars.discourse-cdn.com/v4/letter/j/da6949/32.png) [@jonathonracz](https://forum.juce.com/u/jonathonracz)\ **Post date:** [May 20, 2017, 1:04am UTC](https://forum.juce.com/t/best-way-to-update-the-gui-parameters/7330/5 "2017-05-20T01:04:35Z")
Yep. It’s not magic; these are still in use because they’re simple and they work. The only real changes are to how the underlying data model works, i.e. we now have useful structures like AudioProcessorValueTreeState which can manage parameters and such for us but under the hood it’s still updated via listeners. ---
**Author:** ![matthieu-brucher](https://avatars.discourse-cdn.com/v4/letter/m/a5b964/32.png) [@matthieu-brucher](https://forum.juce.com/u/matthieu-brucher)\ **Post date:** [May 20, 2017, 8:48am UTC](https://forum.juce.com/t/best-way-to-update-the-gui-parameters/7330/6 "2017-05-20T08:48:12Z")
I saw the tree state class indeed. It makes things better in terms of design, the last really ugly part is the bunch of tests in the processBlock method. I suppose this may also be a way to do A/B comparison. The question I have would be to know if getting a child from the value tree state return a reference to it or a new tree. ---
**Author:** ![ttg](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/ttg/32/14456_2.png) [@ttg](https://forum.juce.com/u/ttg)\ **Post date:** [May 21, 2017, 9:21am UTC](https://forum.juce.com/t/best-way-to-update-the-gui-parameters/7330/7 "2017-05-21T09:21:44Z")
My current favourite way: Summary, as Jules wrote regarding Tracktion somewhere on the forum (this was in context of project load/save in Traktion and real time values such as region fades/gain/automation etc…). Best would be to have dupes of vars used for the read part or pointers. AudioProcessorValueTreeState there is float\* ``` AudioProcessorValueTreeState::getRawParameterValue ( StringRef parameterID ) const ``` so once linked Editor element (slider/button) updates you’re good to go since you’re reading the pointer. For sub-components where you set parameters by setMyParameter(float newVal) I’ve simply set a juce::Value reffered to my UI Value. and a listener on changes. so each time Value changed if call the proper setMyParameter(mValue.getValueObject())… ---
**Author:** ![kunitoki](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kunitoki/32/15_2.png) [@kunitoki](https://forum.juce.com/u/kunitoki)\ **Post date:** [May 22, 2017, 5:54am UTC](https://forum.juce.com/t/best-way-to-update-the-gui-parameters/7330/8 "2017-05-22T05:54:17Z")
i currently use preallocated non blocking fifo queues, and dequeue them in a ui timer callback, eventually packing multiple updates to the same “elements” together. this works pretty nicely, and avoid that you refresh all your components every callback ---
**Author:** ![JuceUser1980](https://avatars.discourse-cdn.com/v4/letter/j/ecae2f/32.png) [@JuceUser1980](https://forum.juce.com/u/JuceUser1980)\ **Post date:** [March 27, 2019, 8:58am UTC](https://forum.juce.com/t/best-way-to-update-the-gui-parameters/7330/9 "2019-03-27T08:58:12Z")
Mind sharing an example of this? How does one go about pre-allocating and passing the FIFO to the timer constructor and callback? Samples of the timer class and the caller’s instantiation would be great. ---
**Author:** ![kunitoki](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/kunitoki/32/15_2.png) [@kunitoki](https://forum.juce.com/u/kunitoki)\ **Post date:** [March 30, 2019, 9:00pm UTC](https://forum.juce.com/t/best-way-to-update-the-gui-parameters/7330/10 "2019-03-30T21:00:05Z")
nothing really fancy. get your mpsc lockfree fifo ready and big enough to take some parameter change id, then from processBuffer you enqueue the ids of parameters that change from audio thread (and potentially any other thread). then in your timer you poll the fifo and dequeue until empty (or until a certain amount of time elapsed to avoid the audio thread to potentially prevent getting it empty), batch together the same ids if you receive them multiple times and fire off widget updates to those parameter ids. i also poll the fifo in a way that if i don’t get changes i keep the timer lazy, until i get a set of parameter changes then i start polling more frequently using a shorter timer interval. ---
**Author:** ![JuceUser1980](https://avatars.discourse-cdn.com/v4/letter/j/ecae2f/32.png) [@JuceUser1980](https://forum.juce.com/u/JuceUser1980)\ **Post date:** [April 2, 2019, 12:43am UTC](https://forum.juce.com/t/best-way-to-update-the-gui-parameters/7330/11 "2019-04-02T00:43:30Z")
Thank you. C++ question: I’m having trouble passing to the timer constructor, a reference to the fifo, and storing it correctly, so that it remains valid in the callback. How does one do that? I’m confused by the combination of object allocation, lifetime, scope, multithreading, and refs vs ptrs. ---
**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\ **Post date:** [April 2, 2019, 10:18am UTC](https://forum.juce.com/t/best-way-to-update-the-gui-parameters/7330/12 "2019-04-02T10:18:25Z")
@JuceUser1980 the Timer class is best used as interface, i.e. inherited additionally to the class holding your fifo. That way you have access to all members of your fifo in the callback and the lifetime is bound to the lifetime of the fifo. ```auto class MyClassHoldingFifo : public WhatEverYouInherit, private Timer { public: MyClassHoldingFifo() { startTimer (10); } void timerCallback() override { // ... } //... }; ``` ---
**Author:** ![JuceUser1980](https://avatars.discourse-cdn.com/v4/letter/j/ecae2f/32.png) [@JuceUser1980](https://forum.juce.com/u/JuceUser1980)\ **Post date:** [April 4, 2019, 12:12am UTC](https://forum.juce.com/t/best-way-to-update-the-gui-parameters/7330/13 "2019-04-04T00:12:30Z")
Thank you Daniel, very helpful.