I’m testing a JUCE AUv3 plugin with AUM.
When loading from previously saved state in AUM, I hit a ton of message manager assertions, and got this warning:
This application is modifying the autolayout engine from a background thread after the engine was accessed from the main thread. This can lead to engine corruption and weird crashes.`
I assume this is to do with the thread with which the editor is being created.
One the plugin loads, everything seems to work fine.
Has anyone else creating AUv3’s experienced this issue?
Are you restoring AUM from ‘sleep state’ every time - i.e. leaving it running in the background when you do a build/install of your plugin, or are you completely destroying the AUM instance and then restarting it in order to test - and if so, any difference in behaviour?
I’ve run into issues with the ComboBox GUI control not functioning on AUv3 due to threading issues - AUv3 plugins run in a new thread context and therefore cannot easily append child windows to the main view, causing issues - so maybe this is somewhat related to that too …
Yes, I did restore AUM from sleep after a rebuild. I’ll make sure I test from a fresh launch of AUM next time. Thanks for the insight.
Are you still running into this problem, or does loading a new instance of AUM each time fix the issue?
I just tried saving a session with a copy of the AudioPluginDemo AUv3, and then clearing and restoring the session a few times with the debugger attached. I don’t see any assertions in this case.
If I install a new copy of the AUv3 while AUM is running, then AUM notices that the plugin has become invalid, and asks to reload it. However, reloading the plugin causes AUM to crash. I’ve tried debugging this a bit by sticking breakpoints on all of the AUv3 member functions, but the crash seems to happen at a different point each time, so it’s not clear whether the problem is caused by the plugin. Annoyingly, the debugger exits immediately after the crash, so I can’t examine the stack trace at the point of the crash.