I came here to post about a long-standing issue that I have been observing for several years now, both with JUCE 6 and 7, and with plugins made by multiple different developers/brands.
Summary: when continuously adjusting a control (such as a knob or a slider), the GUI will freeze for 0.5-1 second once in a while. Usually it happens every 10-20 seconds. This doesn’t seem to happen when the GUI is being updated during parameter automation, only when parameters are adjusted via continuous mouse events. Below are two videos that depict the issue with Sinevibes Dipole v2 plugin and Rhizomatic Plasmonic plugin: the cursor is constantly being moved left-right or up-down, but after a while the GUI just locks up, then again continues to redraw/update itself (and eventually will lock up again, all in a cycle).
This happens on macOS only, it seems - haven’t yet seen it on Windows. Also, in my particular case it’s on Apple Silicon, but I can try our Intel test machines too and report back.
I have seen this happen on both JUCE 6 and 7, with or without JUCE_COREGRAPHICS_RENDER_WITH_MULTIPLE_PAINT_CALLS enabled. Currently seeing it on the very latest JUCE 7.0.8. Also experienced it with software from Rhizomatic, refX, KORG, AudioRealism, and others. So it doesn’t seem like it’s something that we coded in a certain way.
Any clues on what this might be? Mouse event queue overload? Any chance this will be fixed?
Ok strange. The only plugins that use “coded” UI design that I made are Deleight and the McRocklin Suite. This last had a huge amount of controls, blurs and stuff… never had any issues. Any chance you are on macOS Sonoma? I remember another forum user posted a thread with rendering issues, including UI freeze, under this new macOS version.
Would like to also add that to experience this issue you don’t have to adjust a control for 20-30 seconds without stopping: this issue can happen at ANY moment of use actually. Sometimes it would do this within the first few seconds after opening the UI. So it’s probably not related to the mouse event queue getting piled up… but some kind of sync/timing issue in the event queue?
Okay, after a big round of testing, I have one important thing to report: this issue seems to be only happening in Apple’s Logic Pro X. I have tested AUv2 and VST3 versions in Live, and VST3 versions in Bitwig - I could not replicate this issue. Testing was done with Sinevibes, Rhizomatic and AudioRealism plugins - again, they behave perfectly well in Live and Bitwig, but I can reliably replicate this GUI freeze issue in Logic (even without rapid control adjustment, even within the first 3-4-5 seconds after opening the GUI).
So the verdict is this: there is something in Logic that can’t reliably handle the stream of parameter change data from JUCE plugins. Those plugins that implement sending such parameter change events strictly via a custom timer are supposedly fine. But plugins that send parameter change events on every mouse drag event cause this hiccup between JUCE and Logic. Any idea how this can be fixed? Should I file a bug report with Apple?
Have you tested any non-JUCE plugins? If you see the same issue in non-JUCE plugins, it could be a problem in Logic, especially given that other DAWs don’t seem to have the same issue.
We have done tests with a few fellow developers and came to the conclusion that this can indeed happen with other frameworks - including QT for example. So this is definitely a Logic issue. However a question remains, why this problem doesn’t manifest install with native Cocoa-based AudioUnit plugins? Do they somehow have a shorter/faster path for communicating parameter change events?
According to some testing I’ve done, Logic can handle about 4 parameter change transactions per second, and is generally slower in this regard than other DAWs.
A parameter change transaction is an exchange beginning with a kAudioUnitEvent_BeginParameterChangeGesture message, followed by one or more parameter changes, and then ending with a kAudioUnitEvent_EndParameterChangeGesture.
If I bind a full transaction on every state change of a slider, then I can trigger the GUI freeze with the Apple supplied example AudioUnit project.
So the goal would be to limit the number of such transactions, and instead send many parameter changes in between a single begin/end gesture pair. This is what the JUCE SliderAttachment does.
Could it be that the problematic example projects are sending a full transaction for every value change event?
In our implementation we send the begin gesture on mouse down, parameter change events on mouse moved, and the end gesture on mouse up. This does then seem like the correct/safe way to do it, right?
Now that you say it, I did another test. I’m getting these occasional freezes with the Apple example even if I do a single transaction with lots of parameter updates inside.
