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:
- its Editor should also be a Timer. The timer should be started on Editor construction and (obviously) stopped when the Editor is destroyed.
- in the timerCallback(), called for example every couple of seconds, it writes a line with a timestamp to a known file (for example, a text file with a given name on the Desktop, creating it whenever it is not present yet)
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.
I knew Ableton would be cool
Yep, listed in the bug fixes for b2 releases today.
Hi, @JFelliz would you be interested in taking a look here? MessageManagerLock caused crash on Ableton Live 11.3.2 - #9 by mcmartin . Seems the latest fix by Ableton might cause some other issues.