FR: Thread-safe `repaint`

[eyalamir]

The problem to me is with ParameterListener and the ergonomics of similar library objects in JUCE.
Both should operate asynchronously internally (with a Timer) and only send messages on the message thread.

So for example my 'ParamListener` works like this, with the user not worrying about thread safety.

struct MyComponent: Component
{
    MyComponent(AudioParameterFloat& param)
        : listener(param, [&] { repaint(); }) 
{}
    
    ParamListener listener;
};

It’s also possible to dispatch the change right away if we’re already in the message thread, but JUCE’s current message thread check needs to be updated for it to work, see here:

Make isThisTheMessageThread() lock free

The Message Manager method isThisTheMessageThread() is many times called from the audio thread. One example from the JUCE code itself is ParameterAttachment void ParameterAttachment::parameterValueChanged (int, float newValue) { lastValue = newValue; if (MessageManager::getInstance()->isThisTheMessageThread()) { However, the implementation of that function locks, and isn’t suitable to use in the audio thread. bool MessageManager::isThisTheMessageThread() const noexcept { con…

Also I think it’s really suspicious that UndoManager does something in another thread - this sounds like a problem to solve on the plugin top level - APVTS functions should not be called on a non-message thread, so if your setStateInformation is called from the thread, you should defer it to the message thread IMO - which JUCE can also solve internally but the user can solve as well.