A Quest for Optimal Ableton Performance

Discuss music production with Ableton Live.
Post Reply
e.x.p.
Posts: 8
Joined: Sat Jul 23, 2022 2:42 am

A Quest for Optimal Ableton Performance

Post by e.x.p. » Tue Jul 26, 2022 10:34 pm

Over the last week I’ve been trying to answer the following question: Is Ableton inherently slow?

Background: I’ve been a daily Ableton user for the last five years. It has been my DAW of choice from the beginning and until recently it was the only one I’d ever used. Since the release of Live 10 I began to notice a growing number of complaints online regarding Ableton’s performance, but I never understood why. That changed after I tried Bitwig. But before we go any further, let’s define “slow”.

When I say Ableton is slow, I’m referring to project load times and the time it takes to load certain actions within the DAW. These actions include adding and removing stock effects, stock instruments, plugins, racks, tracks, and groups, as well changing channel routings and moving tracks and effects around a project. In my experience, these load times are directly related to the total number of effects being used within the project. For example, it takes Ableton a few seconds to load a completely blank project and the above actions, such as adding a new track, occur instantly. Add the tracks and effects contained within my default template and it now takes 19 seconds to load the project and 1.15 seconds to load actions. And, as expected, these numbers only grow as the project gets bigger.

In comparison, it takes Bitwig 3 seconds to open an identical template and actions are loaded without any delay whatsoever, just like the empty Ableton project. It would be easy to conclude that Bitwig is fundamentally faster than Ableton, but after digging through hundreds of threads, I'm not convinced. For every post seeking help with performance it seemed like there was another relaying the opposite experience. For every person asking why their sets take minutes to load, there was another saying it never takes more than fifteen seconds, even for their largest projects. So I wanted to know whether this sluggishness was in fact a part of Ableton or if something else was responsible and if anything could be done to optimize Ableton's performance.

----------

My Specs:
i7-9750H
GTX 1660 Ti
32gb RAM
2x 1TB WD SN750 NVME SSD's
Motu M4 Interface
Windows 10
Ableton 11

60 Channel Test:
To test the impact of effects on responsiveness, I created a blank project and added my default track. In the beginning, this track was set up as follows:

Image

With 60 instances of this track, it took 2.7 seconds to load a new audio channel.

My first thought was, is it the track count or is it the effects? Running the same sixty channel test with blank tracks resulted in a near instant new track load. So it wasn’t the track count, it was the processing. With this in mind I would make one change to the default track, create 60 instances, record the time it took to add a new track, then revert the change and repeat the process.

Removing Pro-Q3 dropped the time by 0.3s.
Removing BC (Blue Cat's Gain plugin) dropped 0.3s.
Removing M/S (Utility mid/side split rack) dropped 0.65s.
Removing Gain (just a Utility) dropped 0.45s.
Removing M/S and Gain together dropped 0.9s.
Removing StandardClip dropped 0.2s.
Removing Spectrum x2 + Utility dropped 0.15s.

So far the results made sense. Fewer effects = less delay. But it was the more unexpected outcomes I found to be the most useful.

Ungrouping the Level rack dropped 0.45s.
Combining every effect, including the Level rack, into a new rack added 1.1s.
Takeaway: Racks are some of the largest contributors to sluggishness (but not always).

Grouping M/S and Gain together while inside the Level rack dropped 0.25s, while grouping them together outside the Level rack added 0.15s.
Takeaway: Racking within a rack can sometimes decrease delay.

Ungrouping Blue Cat increases the time by 0.15s.
Takeaway: Racks containing a single plugin can potentially decrease delay.

Replacing Pro-Q 3 with EQ8 made no difference.
Takeaway: Stock effects may contribute the same amount of delay as their equivalent VST’s, though more testing would need to be done to be certain this isn’t an isolated case.

Unmapping the Gain macro - no difference.
Takeaway: Macros do not seem to contribute to sluggishness (more testing needed to be sure).

Freezing all 60 channels - no difference.
Takeaway: Freezing tracks makes no difference.

Some more miscellaneous testing:
Disabling mono inputs and outputs - no difference.
Removing the auto-updating channel numbers - no difference.
Unplugging the interface dropped 0.4s but running off of the built-in card had no effect so the interface itself likely does not contribute, or at the very least it performs the same as the stock sound card.

Summary: The key to preventing slow down is using as little processing and as few racks as possible during the writing process. This also means cutting the effects on your default audio and midi tracks to the bare minimum, as well as deleting any unused processing as you write. I find the effects on my default tracks important to my workflow and so ultimately I chose to ungroup the Level rack (since it served no functional purpose) and leave everything else, while making a conscious effort to delete any unused processing while writing.

I know this is often the advice given to those seeking to reduce CPU load, but I never experience CPU problems. This is about workflow. Nothing kills momentum more than having nearly every action be preceded by a five to ten second delay and that’s exactly what would happen every time I began making real progress on a project. So from here I wanted to know what sort of impact minimizing the use of processing and racks could have on a real world example.

----------

Project Optimization:
I took a recently finished tune and cut away all the unnecessary processing, as well as some unused channels. I was left with a 65 track project. The bass design was done in a separate session, but there were still a handful of synths and there was processing taking place on every channel.

Original Project Load Time: 100 seconds
Optimized Project Load Time: 50 seconds

Original Action Response Time: 5 seconds
Optimized Action Response Time: 2.85 seconds

By cutting away only what wasn’t being used and by ungrouping unnecessary racks, I was able to cut the project load time in half and shave off over two seconds from the time it takes to perform an action like adding an effect. But these times didn’t stay consistent.

After some Ableton restarts the load times became 55 seconds and 3.3 seconds.
Following another restart, the load times became 75 seconds and 3.3 seconds.
Another restart, 65 seconds and 3.3 seconds.
I put the computer to sleep for a couple hours and tried again.
It dropped back down to 50 and 3 seconds. What’s with the variation? Could it be my PC?

Here’s a list of everything else I tried in an attempt to stabilize / further decrease load times:
-killing the index process
-updating all plugins
-Collect All and Save
-removing my music library folder from the sidebar
-closing an 8 tab Firefox session
-windows Disk Cleanup
-CCleaner
-deleting unused MIDI mappings
-setting the minimum processor speed to 100% (only succeeded in making the fans go crazy)

None of the above made any difference. The only thing that helped was disabling Windows Security. This cut about 5 seconds of project load time. But even with a load time of 45 seconds and a response time of 3 seconds, Ableton is still nowhere near Bitwig in terms of speed. So let’s circle back to the original question: Is Ableton slow? I don’t know. It’s possible my experience is an isolated one. Maybe there’s something wrong with my computer. Maybe some people see the same responsiveness in Ableton as I see in Bitwig. Although even professional producers with the most powerful computers seem to experience delay, at least to some degree. Nasko recently streamed a 90 track project with a response time of 1.65 seconds and during one of Culprate’s album streams he had a 130 track project with a 4.5 second delay.

This whole thing started as a reaction to Bitwig’s speed. Prior to downloading the trial I had never even thought about how slow things were happening in Ableton. It was just the way music software operated. But even now I have no desire to make a change. I love Ableton, I just wish it were faster. I hope this thread can serve as the spark for a discussion surrounding Ableton’s performance and that some of the things I’ve come across might be useful to anyone battling a sluggish DAW. So let’s hear it:

What is your experience with Ableton in terms of responsiveness? Is it at all similar to mine?
How long does it take to load a typical finished project?
How long does it take to do something like adding a new track in a finished project?
If you’ve tried both, how does Ableton stack up to Bitwig in regard to load times?
Do you have any recommendations for decreasing load times?

Looking forward to talking Ableton!

Calagan
Posts: 268
Joined: Fri Jul 24, 2015 4:44 am

Re: A Quest for Optimal Ableton Performance

Post by Calagan » Wed Jul 27, 2022 8:34 am

Very interesting post.
I had similar issues as you, and even if upgrading to a M1 pro laptop did improve things a lot, I still experience the same poor performances in some situations.

I didn't test as methodically as you, but my experience is quite similar : like you I experienced that racks and grouping add to the lack of responsiveness, but I think also that automations (when there's a lot of them) can cause some CPU issues, specially when triggering play/stop/launching scene/back to arrangement/reactivate automation...
And also some augmented loading times : the worst sets I have in terms of loading time are the ones with the most "editing" in them (racks, groups, automations, etc. etc.), not necessarily those with the biggest number of plugins.

Anyway, it's a very interesting thread.
I don't know exctly how we could test it "scientifically", but I think it's quite obvious Live could have some performance optimizations in these areas.

I created recently a thread regarding CPU peaks when triggering play/stop/launching scene/back to arrangement/reactivate automation (viewtopic.php?f=1&t=245368)
I noticed that in the set I use on stage, that is essentially racks within racks within racks with a lot of automations, even if I deactivate absolutely everything (clips, plugins, racks, etc. etc.), and the CPU use is around 15%, I still have CPU peaks when triggering play/stop/launching scene/back to arrangement/reactivate automation
I sent a detailed report to the Ableton support, with a video explaining my problem, but had no feedback until now...

So yes, I guess there is an issue and they may (or may not) investigate the problem...
Maybe it's inherent to Live's code, maybe it's possible to improve things a lot.
I don't know, but I think something went wrong with Live 10 : I don't remember such issues in Live 9, and I'm even not sure it was an issue at the beginning of Live 10 (but I'm not sure).

DunedinDragon
Posts: 106
Joined: Thu Jul 22, 2021 5:46 pm

Re: A Quest for Optimal Ableton Performance

Post by DunedinDragon » Wed Jul 27, 2022 8:53 am

I'm relatively new to Ableton after having spent many years using Sonar Platinum and I can't say it varied that much from what I've experienced before. What is noticeable to me is that Ableton appears to be affected most in two very specific ways.

The way I use Ableton is probably very different from many people. I'm a heavy user of sampled instrument libraries. I tend to use Kontakt as my primary source of plugins rather than the built in plugins and libraries in Ableton. I use Ableton on two different computers. One is my pure studio setup which I run on a fairly high end Windows desktop configuration, the other is my live playback system on a high end Windows laptop. My laptop playback system runs tracks and MIDI automation files, but all audio tracks have been converted to WAV files, so that system performs very efficiently as one would expect compared to my studio setup.

Because my projects are so reliant on instrument libraries that can be extraordinarily large, I initially found that I needed to upgrade my studio system to 16gb of memory and abandon using USB storage and replace it with high speed, high density SSD storage to reduce CPU impact and load time performance. Load time performance is significantly impacted by the loading of these libraries, but is significantly better on Kontakt certified libraries compared to non-certified ones. In the rare cases in which I use Ableton plugins and libraries, those are significantly better on load times and CPU usage, but that would be expected as those aren't sample libraries generally but tend to be synth based instruments. Once these libraries are loaded, they're all relatively similar in performance and CPU usage. Obviously the laptop live performance system is pretty much instantaneous in all situations since it's only using converted WAV files.

I'm not sure that adds much to this discussion other than to point out that the type of plugins and libraries are THE most significant factor in load times and performance in my experience.

Mark Williams
Posts: 898
Joined: Sun Aug 10, 2014 2:43 pm
Location: Kent

Re: A Quest for Optimal Ableton Performance

Post by Mark Williams » Wed Jul 27, 2022 9:49 am

Certain plugins cause slow loading, especially those that ‘call home’.
Live 11, M1 Mac Mini, Push 2, Scarlett 18i20 & ADA8200, Softube Console 1 Mk2, Deepmind12, Hydrasynth, Cobalt 8M, Moog Subsequent 25, IK Uno Synth Pro, Plethora X3, Nord Drum 3P

Calagan
Posts: 268
Joined: Fri Jul 24, 2015 4:44 am

Re: A Quest for Optimal Ableton Performance

Post by Calagan » Wed Jul 27, 2022 9:51 am

Funny : 2h after my post, I received an answer from the Ableton support.
They admit the issue and say it's not a bug but the way Live is working.

One interesting note regarding my issue : they say that each time one trigger play/stop/back to arrangement/reactivate automation, Live sends a "midi note off" message (CC123) to ALL INSTRUMENT DEVICES IN THE SET.
This can cause a CPU spike.

I wonder if it can be filtered (with a M4L device) and if yes, if it causes another kind of troubles...

e.x.p.
Posts: 8
Joined: Sat Jul 23, 2022 2:42 am

Re: A Quest for Optimal Ableton Performance

Post by e.x.p. » Mon Aug 01, 2022 8:43 pm

For anyone stumbling across this thread in the future:

Based on testing, reading, and replies here and elsewhere, I feel Ableton's poor performance is most likely a fault of the software itself.
Without any way to know when and if performance will be overhauled, the best way to minimize project load times and action response times is to use as little processing as possible. The more devices and plugins contained within a project, the slower Ableton becomes. Be especially wary of unnecessary effect racks and drum racks. Try to build a habit of removing unused elements during the writing process as well as committing to audio when possible. Never leave fully loaded drum racks running live in a project. Once the part is written, transfer what's being used to a new track and get rid of everything else.

This thread was more active on r/Ableton so if you're interested in some more discussion it can be found here:
https://www.reddit.com/r/ableton/commen ... rformance/

ethnotronik
Posts: 74
Joined: Wed Feb 16, 2011 4:33 pm

Re: A Quest for Optimal Ableton Performance

Post by ethnotronik » Sat Aug 06, 2022 8:48 pm

Interesting post.
I have been using Macbook pro 2012 and 2015 a lot for live sets, and I have experienced all kinds of spikes and issues, especially when dealing with VST, like NI Komplete, Arturia, Diva. I want to have some of the VST's while playing along with wav loops. The effect rack and chain is an amazing way of organizing effects and chains for the current song. But is there are better and more powerful computer than MBP2015 really? What would I gain in comparison to M1 or a high end PC laptop? I am thinking, I don't know for sure if the performance difference from 2015 macbook would gain 100% in terms of CPU performance. Maybe disk read and write speed is much faster, but not essential. You would normally expect that 2012 vs 2022 mac is a huge leap, but for ableton, it seems not. I am only speaking from my personal experience, and I didn't get too deep into tech analysis and numbers.
Anyway, I am waiting to hear people's experiences, because if not, I am considering two laptops for live.
2012 MBP 16GB RAM 512SSD 10.11.x, Push2, Xone K2, Minilab MK2, Komplete Kontrol25, Model D, Digitone, Roland TR8s, Eventide Timefactor

e.x.p.
Posts: 8
Joined: Sat Jul 23, 2022 2:42 am

Re: A Quest for Optimal Ableton Performance

Post by e.x.p. » Sun Aug 07, 2022 4:07 am

ethnotronik wrote:
Sat Aug 06, 2022 8:48 pm
But is there are better and more powerful computer than MBP2015 really?
For what it's worth, I never experience CPU issues. Even the most extreme projects don't max out the available processing power. So if you're having trouble with spikes and CPU overloads I would imagine any high end laptop from the last few years will solve that problem.

ozinga
Posts: 87
Joined: Fri Mar 05, 2010 11:43 am

Re: A Quest for Optimal Ableton Performance

Post by ozinga » Sun Aug 07, 2022 5:18 am

e.x.p. wrote:
Mon Aug 01, 2022 8:43 pm
Try to build a habit of removing unused elements during the writing process as well as committing to audio when possible. Never leave fully loaded drum racks running live in a project. Once the part is written, transfer what's being used to a new track and get rid of everything else.

Exactly why there is need for bounce in place+disable and hide track feature.

jlgrimes
Posts: 1773
Joined: Mon Jan 22, 2007 1:55 am
Location: Atlanta, Ga

Re: A Quest for Optimal Ableton Performance

Post by jlgrimes » Mon Aug 08, 2022 10:33 pm

Ableton has gotten slower over the years but it got really awful (about 5 minutes to load projects with audio) when I was on a Mac around version 9 or 10. I went to Windows which pretty much fixed the issue (within 1 minute to load projects with audio), but Ableton does seem a bit slower than other DAWs in this matter.

baseinstinct
Posts: 927
Joined: Sun Feb 24, 2008 3:45 am

Re: A Quest for Optimal Ableton Performance

Post by baseinstinct » Sat Aug 13, 2022 7:34 pm

I have not been seeing any deterioration from 9 to 11 on an old laptop thinkpad x230, whether project opening or playback. Obviously, a different ballpark though.
Could it be that the deterioration affects newer processor/mobo technologies?

x3000
Posts: 5
Joined: Wed Oct 04, 2023 2:47 pm

Re: A Quest for Optimal Ableton Performance

Post by x3000 » Wed Oct 04, 2023 3:20 pm

The younger the Live version the slower the whole thing. Thats all.
I have live 8.5 on a macbook 2.1 with 4gb ram and ssd, which is a lame cucumber by today's standards, and it's fast as an arrow.

The algorithms seem to have become more elaborate. something else to note: the index service in Live needs a lot of resources, but once it's through, it runs.

I also have live 11.3 on a zbook g3 with a quadcore xeon, 64gb ram and a lot of nvme-ssd and it sometimes feels like a snail. ok, a g3 is also already old, but this box is actually still fast as an arrow and some with a new 3000€ laptop has a lot of dropouts, which I never have.

it's ok, but the old macbook feels much faster with it - but just with live 8.5 - the last version that ran on this box (32bit).

Also to note: a modular system like Max4Live and also Reaktor will consume more than a closed system, because you can optimize the closed system in the code better.

What surprises me is that Bitwig is supposed to be faster, although it is written in Java. But in the end, it's not the programming language that matters, but how much the code is optimized. A Python program can be significantly faster than one written in assembler if it has been cleverly optimized.

I think it would be very good if ableton would add less new features and optimize the code more, so that the whole thing runs faster. but maybe I'm doing the developers wrong.

Always a good idea:
- turn off the virus scanner
- activate the flight mode
- disable any virtualization stuff
- maybe also disable any encryption
- the onboard-graphics is enough, if available (disable nvidia or leave it on auto-switch)
- disable the search index of windows!

ribon
Posts: 1
Joined: Sat Dec 09, 2023 10:16 am

Re: A Quest for Optimal Ableton Performance

Post by ribon » Sat Dec 09, 2023 10:44 am

After experimenting a lot with the Live API/LOM (using the excellent ableton-js library) i've come to the conclusion that it's most likely the updating of the object graph that slows down to a crawl at a certain point.

if you create a really large project consisting of just nested racks with all devices turned off you'll still get this extreme slowdown despite the actual audio processing not taking up any CPU. there is also no correlation between a device's CPU usage/complexity in terms of audio processing and the impact it has on slowing down live when adding/removing/moving new devices. instead it's the complexity in terms of live's object model that's the key factor here, with rack devices being the worst culprit - likely because they add depth levels to the object graph.

to further test this hypothesis i've created a project with 8 tracks, each hosting an instrument rack containing all stock x0x core kits, followed by 3 fx racks containing one instance each of all stock devices. this amounts to over 1000 devices within the set, and at this point the GUI slows to a crawl when adding or moving devices.

i have then written a small nodejs application that queries the live API for the entire object graph of the projects, caches it locally and then periodically sends OSC requests to enable/disable different combinations of FX and Instrument chains on all 8 tracks while monitoring the time it takes to change the routing.

the results are pretty clear: the CPU meter consistently stays below 20% on my intel i5 machine, which is expected because there's a maximum of 3 FX processing each drum rack at a time. enabling/disabling the chains of all racks in all 8 tracks at the same time takes 20 milliseconds, which is probably just the bottleneck of OSC communication - in other words it's nearly instant.


TL;DR:
in theory there is no problem having 1000+ devices in your live set provided they're not all running at the same time. disabled devices have absolutely no impact on the performance of your set, no matter what kinds of devices they are (yes this even includes max4live devices).
however, as the complexity of the live set grows live will take more and more time to update the object graph whenever you move, add or remove devices in your live set.

i have no idea what the underlying source code looks like, and i don't know whether it's just the updating of the LOM that takes so long or if updating the actual audio graph also plays a role here. but to me it seems like no matter where you change the graph, the whole thing gets updated and the delay stays the same.

take all of this with a grain of salt. i'm just a user and have no access to the source code, this is all pure speculation based on what i can measure given the tools we have.

e.x.p.
Posts: 8
Joined: Sat Jul 23, 2022 2:42 am

Re: A Quest for Optimal Ableton Performance

Post by e.x.p. » Sat Dec 09, 2023 7:28 pm

ribon wrote:
Sat Dec 09, 2023 10:44 am
After experimenting a lot with the Live API/LOM (using the excellent ableton-js library) i've come to the conclusion that it's most likely the updating of the object graph that slows down to a crawl at a certain point.
    This is incredibly insightful. I'm not well-versed in the world of programming, but it sounds like this lends support for what some producers were saying on Twitter following the announcement of Live 12, namely that Live's sluggishness is a result of poor GUI handling. I would pay for an upgrade if the only thing it did was address this issue. So many people were complaining about the lack of ARA support, bounce in place, and group freezing + flattening. The main function of all of these features would be to save time and yet the time they would save is minuscule compared to the amount of time every single user would save if they addressed the GUI lag. But it feels like so many Ableton users are so blissfully unaware of just how slow it is that it will never be addressed because there will never be any real demand. Maybe we'll get lucky and it will magically be fixed in 12, but from what I've seen it looks like we're in line for more of the same.

    Post Reply