We can actually (see my post above). We can decide to destroy all children and release all memory when the UI isn’t showing.
On another note, I suspect this issue isn’t Ableton Live specific though, so fixing it on the plugin dev side (or on the JUCE side maybe) is totally possible.
I have been discussing this matter with other users on Reddit, who have shared valuable insights gained from conversations with Ableton’s developers.
Live’s primary function is to deliver uninterrupted audio, and as a result, the user interface thread may be impacted by high CPU usage, as it is given a lower priority. This design choice can create challenges for third-party developers, who must ensure flawless execution of their plugins in order to maintain operability within Live sessions. However, some users may find this design choice to be impractical and prefer to have the ability to prioritize specific tasks based on their project needs.
In conclusion, if a plugin is poorly coded or lacks its own framework, or if JUCE fails to effectively allocate GPU rendering, this could result in a deteriorating workflow experience within Ableton Live. Unfortunately, Ableton has not addressed this issue, as they consider it a feature rather than a flaw.
I’m not sure I agree with that feature vs flaw analysis because if it was a feature of Live to be running the UIs in the background in an invisible state at all the times (sure that’s their prerogative to do if they want) then Live would not be calling the UI destructor when the user manually opens and closes a UI. As things stand you can improve Live UI performance by going through a restored project or duplicated track(s) and methodically open and close all plug-in UIs which then invokes the plug-in destructors of the running but hidden default state of UIs. Live is happy not to run the UIs perpetually, it just doesn’t default to such a state, which seems more in the flaw than feature category to me.
If the DAW can be manually manipulated into performing better with steps like that, I don’t think it’s got much to do with plugins not deferring work to the GPU or that they’re poorly coded.
I’d be interested to know their rationale for constructing and running potentially hundreds of invisible plug-in UIs before their first opening but not on their second opening, if this is all deliberate.
So this would be something that Ableton could address hypothetically…
On a modern machine, I would consider anything below 60 fps to be choppy & unacceptable.
It won’t be long before 120Hz is a fairly common expectation on Macs, and PC users were there many years ago (many now thinking 144 Hz is a bare minimum).
Visual perception has its limits
For sure, but those limits are definitely ≥ 60 fps for most people.
Check out this video that showcases the contrasting UI performance of MacOS (M1 Pro Macbook Pro, 32GB RAM) and Windows (Custom PC with 9900K, RTX 3090, and 32GB RAM). To ensure that no VSTs are causing any potential issues, I’ve loaded a Live demo project that solely utilizes stock plugins. The UI on MacOS appears noticeably smoother, leading me to believe that the problem lies more with Live than with third party plugins.
i think it’s unfair of ableton to accuse plugin developers they could do a better job handling performance of editors that aren’t even showing when they could just not open them like every reasonable daw does. a plugin dev should only be responsible for keeping their interfaces’ loading times short when the user actively opens them. if ableton is cool with the entire daw lagging because of this it’s their own problem
Hello everyone, I’m trully gratefull for the insight of everyone in this thread.
My sets tend to be quite large and my computers are powerful. I am usually able to keep the Ableton CPU meter around 50% and the GPU load minimal. However, I still experience UI slugishness, lags and slowdowns that can start making my sets unoperable. These sets, no matter how light on the CPU can take me hours to troubleshoot. I have tried various solutions such as freezing tracks, flattening them, removing or replacing plugins, and even reverting to prior sessions to identify any problematic changes.
From a user’s perspective, this situation is quite frustrating. It feels like buying a car with a hidden deffect, like a cap on speed-limit that was not disclosed at the time of purchase. I can drive it above 60 miles per hour “at my own risk.”
I have shared this thread with an Ableton tech support representative on a support ticket about the very subject of this thread here that has been going on for a couple of years, wihout any solution to these issues. Here is their response:
I can see a lot of false claims, accusations, and misunderstandings when reading that forum thread.
Yet as mentioned before, there are no new insights there.
Should there be an issue with the implementation of a certain plugin, then any plugin developer has the possibility to reach out to us directly (Such requests are reviewed with special care).
This avoids double communication and miscommunication with each involved party’s customers.
Generally speaking, in Live, any plugin UI is not initialized until it got opened.
Opening the plugin UI happens when a user has the Auto-Open Plugin Windows turned on and loads a new instance for the first time.
The only other action is indeed when opening plugin UIs manually.
Loading existing projects doesn’t open the UI. Thus they shouldn’t contribute to the performance baseline and RAM load except for the needed processing for samples, audio, and parameter automation.
As mentioned in my last email, there is really not much to say here.
I kindly ask you once more to refrain from attempts to discuss this topic further.
**We already have about two years’ worth of communication and don’t want to take too much of your and our time in this regard.
Moving forward, any development will be well thought of and take cases such as yours into consideration (e.g. the idea of a performance mode is not a new one). Yet I can’t tell if or when a change will happen in the future.
My personal advice for big sets with many plugins would be to manually open and close plugin UIs and/or be aware of the impact it can have to use the auto-hide function in Live.
Thanks for your understanding.
It’s possible that the support person I spoke with may not be aware of this issue, or be confused about it, as they may not be a developer.
Is there a way to empirically demonstrate and observe that the Editors are indeed being loaded into memory during project loading?
In a development environment - of course there is
You can debug the most basic plugin (say, the empty JUCE VST3 plugin template, or one of the VST3 SDK examples), and place a log message or a breakpoint on the constructor and destructor for the editor.
Even without a debugger attached, this can be demonstrated also to a support employee with a plug-in like this:
With such a plug-in inserted in a Live project, it is easy to look into the aforementioned text file to check whether new entries have been written there, while the editor was created (but not displayed) after project load.
Then, it should be equally demonstrable that those entries stop being written when the editor is displayed and then closed again.
Ableton launched with .als project as parameter, with debug breakpoint set in the editor constructor. Call stack clearly demonstrates Ableton’s code calling into the createView VST-3 API. This happens even before the Ableton user interface loads.
Just to make it clear, I don’t even know if it’s wrong for Ableton to do this. But we should all get on the same page and the customer support thread would seem to demonstrate we aren’t.
But proving that editor creation happens during project load is not enough as a definitive proof, because the DAW may construct the editor as part of each plug-in initialization, and then immediately destroy it.
What we want to prove, is that the editors are created and stay alive after the project has been fully loaded.
In my experiments it does stay alive until you manually open and close the editor from Ableton’s UI once upon first load. You can test this yourself and see what you find.
I had a mock plug-in that debugged output on editor constructor, destructor, and on a timer every second that was started in the editor’s constructor.
Perhaps some more digging is warranted, but the results so far don’t look good. And in my experiments it was not just Ableton that behaved this way.
What I did not do, and may be the next step is to create a bunch of plug-in instances, give each instance a unique ID, and confirm through either debug output or logging to file, that every single instance in the project behaves this way.
I’ve just heard back from a lead-dev friend of mine from a reputable company, he corroborates Cymatic’s finding. When loading a Live project, all editors are loaded into memory and remain invisible. He even pushed his tests to corroborate the assumption that the editors are not destroyed and remain in memory until UI is manually opened and closed. His test involved 100 instances of a small plugin, observations were done on both platforms, Xcode for Mac and Visual Studio for windows, both showed editors being constructed, and never destroyed, unless manually destroyed. What would be the best way forward?
Happy to report that these issues may have been fixed in the latest Public Beta - I was able to get a hold of some ears @ ableton (noone in techsupport, but directly with the dev team)
They were very gracious and helpfull and took it on their shoulders to figure out a fix that benefits all parties involved.
These issues may have been fixed once and for all.
The correct Beta would be : 11.3.1b2
Brilliant, thank you for speaking with them 
awesome, Ableton rocks.
Thanks for helping to link the lines of communication.
