I’m getting a JUCE_ASSERT_MESSAGE_MANAGER_IS_LOCKED assertion in several components that are registered as parameters listeners. It only seems to happen (so far as I’ve found) in AAX in ProTools, when clicking the Compare button to switch between the current plugin state and the cached plugin state.

The problem seems to stem from the fact that the parameters are restored from the setStateInformation() function, which causes parameter change listeners to have their parameterChanged() function called, which then proceeds to execute certain drawing updates that in the end fire this assertion.

I thought maybe I could just acquire a message manager lock on the current thread, but that just hangs everything, and I have to kill ProTools.

How can I safely update my components in this situation? My only thought so far would be to not use listeners for those parameters, and instead use my timer callbacks to query the parameters in question, and updated my GUI if those values have changed.

There does not seem to be a similar problem with the listeners used by my buttons, sliders, etc., however. They update fine without asserting, so I’m a little confused why the Compare function in ProTools is causing this, and how best to get around it. Thoughts?

or reload your session from setStateInformation using

if (juce::MessageManager::getInstance()->isThisTheMessageThread())

where fn is a std:function that does your actual loading UI thread notification

I don’t understand. The AudioProcessorValueTreeState::Listeners’ parameterChanged() functions are called for me whenever a parameter is changed. I am not calling the listeners myself to update the UI, I am just setting the parameters normally, just as the default code would do when restoring a session.

yep but AAX can call setStateInformation in non message thread which call your listener in non message thread which call your UI in non message thread

either force setStateInformation to be done in message thread
or use some AsyncUpdater for the UI notification to be done in the message thread

1 Like

I vaguely remember that it was possible in AAX to ask for the plugin state being set and read on the message thread. Not sure whether this is available via JUCE or if you have to tweak the AAX wrapper yourself.

otristan’s solution by calling a lambda with the change async is certainly the cleaner way to go. One thing that might go wrong with that is though, that especially during plugin initialisation the MessageManager might not be available resulting either in a crash because juce::MessageManager::getInstance() returns a nullptr or at least callAsync can’t be used and thus the state won’t be set correctly.

Again, it has been quite some time that I came across this and I haven’t looked at the current AAX wrapper so this can be no more than a suggestion for a different perspective.

It has been suggested here: [AAX][PULL REQUEST] Force Protools to do chunk calls in message thread option

but it’s not currently supported by JUCE