AttachedControlBase uses triggerAsyncUpdate?

void AsyncUpdater::triggerAsyncUpdate	(		)	
Causes the callback to be triggered at a later time.

This method returns immediately, after which a callback to the handleAsyncUpdate() method will be made by the message thread as soon as possible.

If an update callback is already pending but hasn't happened yet, calling this method will have no effect.

“It’s thread-safe to call this method from any thread, BUT beware of calling it from a real-time (e.g. audio) thread, because it involves posting a message to the system queue, which means it may block (and in general will do on most OSes).”

    void parameterChanged (const String&, float newValue) override
        lastValue = newValue;

        if (MessageManager::getInstance()->isThisTheMessageThread())
            setValue (newValue);

parameterChanged() is called from the DAW when you do automation stuff. so that function is definitely being called on the AudioThread. Why does this AttachedControlBase, which is used by ALL sliders, buttons and combo boxes that get linked to the APVTS via SliderAttachment/ButtonAttachment/ComboboxAttachment, make use of AsyncUpdater::triggerAsyncUpdate, given the realtime-thread warning in the docs for it?


Can we get some sort of reply or something about this @jules @t0m

1 Like


…is this a theoretical issue or has it been seen to be a problem?

it would great if juce (as a pro audio-framework) can do lock-free messaging (triggerAsyncMessage, sendChangeMessage() etc.) out of the box. (Without using complicated constructs)



1 Like

bump…am also curious if this is an issue in practice


Are people bumping the question? So has somebody a problem IRL?

Well I’m bumping it because Jules in another thread advised it was an issue, someone else said they were getting glitches, and but no-one is saying ‘it’s not a problem in this case’ nor is anyone fixing it :slight_smile:

And right now I’m having to re-implement something like AttachedControlBase which uses it, because AttachedControlBase is private and depends on another private class which is protected from access.

Ah cool, sorry, I didn’t see this in this thread… it sounded like it is waiting for user feedback…

Here you go: