handleAsyncUpdate never called for ValueSource

[flavi0]

Hey there,

I am using a Value with a Listener attached to detect whenever its value has actually changed and react to that (by sending the changed value via OSC). I update via Value::setValue and register a Value::Listener. Note that this hat previously worked, presumably in JUCE 5, but for some reason I’m not seeing any updates anymore.

If I call sendChangeMessage(true) after setting the value I get the callback as expected, however I loose the property that I only get notified when the value is different from the previous value.

I investigated a bit and everything seems correct in so far, that the triggerAsyncUpdate of the ValueSource is correctly called. However, the handleAsyncUpdate never gets executed. I checked by inheriting ValueSource publicly instead of privately from AsyncUpdater and checking isUpdatePending() at different locations, which always returns true. So it seems that the event thread (?) or whoever is responsible for executing the asynchronous updates is not working for some reason.

The code is part of a VST3 Plugin on Linux, hosted in Bitwig Studio.

Thank you,
Patric

[ed95]

Do you provide a plug-in editor, and is the editor open? It sounds related to this issue:

Messages are only being handled while the editor is open

When using JUCE 6.0.8 to create a VST3 plugin on Linux, none of JUCE’s asynchronous messaging utilities relying on the global MessageManager work while the editor is closed. This means that among other things AsyncUpdaters, Timers, and calls to juce::MessageManager::callAsync() won’t do anything until the user opens the plugin’s editor. This seems to be consistent across Bitwig Studio, REAPER, Ardour, Renoise and Carla (which uses JUCE’s own plugin hosting). A minimal example of this (courtesy o…

[flavi0]

Hi, yes indeed that is the same issue! I just enabled the editor component for testing, which is normally not active when I’m running in “headless” mode that sends OSC messages. And the behavior is exactly the same, when the editor window is open I receive the updates, when I close it the updates are queued but never executed. Thanks a lot for spotting this!

Is there anything I could do to support the development team to find a fix for this? Reading the thread, it seems reasonable to just run your own custom event loop thread. Having that tied to the editor and executed as part of the IRunLoop seems to make no sense in many cases. Since plugins can, in general, be used without a UI and just exposing the AudioProcessorParameters in the host, such as in my case. I would gladly support in finding a solution for this and testing any changes, if that helps.

[flavi0]

I realize now why this was working earlier, because in JUCE 5 I was still using a VST2 plugin that implements the event loop differently.

[ed95]

@flavi0

I was still using a VST2 plugin that implements the event loop differently.

Yes, this has never been implemented for VST3 plug-ins.

@flavi0

Is there anything I could do to support the development team to find a fix for this?

Thanks, but it’s fairly clear what we need to do to fix this and will just involve a lot of testing with the interaction between the event loops. We’ll hopefully have some time to look into this soon.

[flavi0]

Great. I’ll work around it by either falling back to VST2 for now or just calling the sendChangeMessage(true) for the time being. Looking forward to a fix, I’m really happy that VST3 support made it to Linux after all. Thanks a lot for the support!

[ed95]

Messages are only being handled while the editor is open

We’ve pushed some commits to the develop branch which should fix this. As predicted, the interaction between the host’s run loop and the shared message thread is a little tricky and there is some variation in how hosts implement the run loop interface so any feedback on the new changes would be appreciated.