I have yet to test it on a simple plug-in but on release builds of one of the products I work this cause a regression.
Opening plug-in editor for VST3 or AU on Ableton Live 10.1 causes audio drop-outs.
We also have customers that report unresponsiveness. UI doesnāt open or takes several minutes etc. Maybe itās caused by a similar issue? These reports are all relatively new.
This is the thread that lead to that commit for some context:
Itās hard to see how removing the callback lock from the editor creation/destruction would cause audio dropouts as now there is a separate critical section to lock around access to the active editor which isnāt used around the processBlock calls. Are you perhaps taking the callback lock somewhere in your plug-in via AudioProcessor::getCallbackLock()?
Are you able to put together a simple example which reproduces this? Iāve taken the audio plug-in template and modified it to output a continuous sine wave and I canāt hear any audio dropouts when closing/opening the editor in Live 10.1 (VST3, AU or VST).
Sorry for the delay. Yes, we use an OpenGL context, so Juce renders faster on Windows. Not sure what you mean with ācustomā. We donāt create one with our own shaders etc, just a standard OpenGL context we then attach to the editor, so all Juce components render faster.
Iāve continued this on the relevant commit thread. In our case Iāve looked into possible locks on the audio thread. Eventually it was the change of adding lock to getting the editor. (weāve used it to determine if we need to process some analysis code).