Introduction
Specs: TERRA ELITE5v2, 64GB RAM, Intel i9-13900HX, Windows 11, GeForce RTX 4070, UAD Apollo Twin USB3, 44.1kHz, 2048 buffer size
Hi everyone,
I’ve been a long-time Live user (since v10) and I’m a genuine fan. I've been using Live for seven years across four high-end Windows machines, and yet I have experienced a particular issue ever since I started out:
The more tracks, devices, plugins, or complex routing a Live Set has, the longer simple actions take to execute—such as:
- Adding/removing/grouping/moving tracks
- Adding/removing/grouping/moving devices or plugins, even if they are lightweight
- Changing routing or sidechain inputs
I have compiled a list of 13 forum entries from past years where this issue has already been discussed at length, never with any satisfying solution or conclusion. I will select a few aspects from these threads and discuss them here in light of my own findings. You can find the list at the end of this post. Throughout this post, I will be referring to [1] and [2] in particular, which I highly recommend reading.
I am an independent artist, music producer, and songwriter. I am also an engineer and nerd. I hold a degree in electrical engineering and have studied music technology for a few semesters. I have a good understanding of signal processing, and I have investigated Live's behavior in certain aspects over the years. I want to share my findings with the community and hopefully encourage Ableton to finally address the problems I am outlining here.
I am posting this both on the "ableton" subreddit and the Ableton Forum to reach as many people as possible.
Tests and Analysis
Comparison with other DAWs
As other users have pointed out in [1] and [2], this is not normal behavior in other DAWs, which leads us to my first simple test: I was loading 500 tracks, with an instance of Soundtoys Decapitator on each track, in both Ableton Live 12.2.1 and Reaper 7.42. Then I added an empty track, which in Live took 5.5 seconds to complete, while in Reaper, it happened instantly.
Loading a second, empty Live set
When I load a large set, adding an empty track can take 8 seconds or more. However, if I open a second instance of Live with a blank set, actions like adding or removing a track or plugin are instant and responsive in the empty set. This finding is interesting because the second instance of Live runs on the very same system and therefore has the same CPU and RAM resources available. However, the lag time in the empty set appears to be unaffected by a busy CPU and full RAM.
These two tests already indicate that it is not the system that is too slow or overloaded, but that the sluggishness is inherently rooted in Live's design, and that it also correlates with the complexity of a project.
Is it a Windows-related issue?
I would like to note that most reports I have found are from Windows users, yet this is likely heavily biased because Windows is a more widely adopted platform than macOS. I have always been an avid Windows user myself. (So far.) In the related thread on Reddit [2], users report experiencing the same issues on macOS; however, in some cases, the problem appears to be less severe than on Windows.
phe__nom posted this:
"It does seem like Mac's might be a little snappier, but it's hard to say for sure. I checked out a few streams with producers using Apple machines, and they were all experiencing at least two seconds of response delay.
Crankdat [100 Tracks] - 2.75s
Frequent [70 Tracks] - 2.2s
San Holo [100 Tracks] - 2.0s"
In [9], badlabelexperience posts
“I had this issue on my macbook for many years, thinking it just was not powerful enough, but I built a PC in 2018 and still have this issue constantly.”
I have seen similar lag times when I was in sessions with other producers. On a heavy set on an M2 Max, I have seen around 2-3 seconds of lag. These numbers are all just anecdotal data. Therefore, I wanted to make an apples-to-..., ehm, Windows comparison.
A while ago, I had the chance to borrow an older Intel MacBook and used the opportunity to compare it to my laptop. The Mac I had available had an older and weaker CPU. Hence, it was to be expected that it would perform worse than the Windows machine. The comparison gives us some interesting insights, nevertheless:
Specs
- MacBook Pro 2019, 32GB RAM, 8-core Intel i9, likely 9th Gen.
- The OS wasn't reporting which exact CPU it had built in, but based on the year, I am guessing it is an Intel i9-9980HK. Here is the benchmark:
- Core Audio @ 44.1kHz, 1024 buffer size
https://www.cpubenchmark.net/cpu.php?id=3451&cpu=Intel+Core+i9-9980HK+%40+2.40GHz
- TERRA ELITE5v2, 64GB RAM, Intel i9-13900HX, Windows 11, GeForce RTX 4070.
- UAD Apollo Twin USB3 @ 44.1kHz, 2048 buffer size
- CPU benchmark: https://www.cpubenchmark.net/cpu.php?id=5205
Test methodology
I opened the Ableton Live 12 demo set, grouped all the tracks, and then duplicated this group multiple times. The master chain was untouched. Then I tested how many groups the computer could play back and measured the lag of the UI.
You can download the test set here:
https://www.dropbox.com/scl/fo/w2tawwrut7eqof5dld1ho/AN---NnIU6Ohp75QY-KUSpY?rlkey=48175qtzjotxgy4kwopmzmqsf&dl=0
Testing playback performance
This test gives a benchmark of the CPU performance of the tested machines. How many groups can the computer play back without audible dropouts? If the CPU meter showed a CPU peak warning, but I couldn't hear an audio dropout, I still counted the test as passed. Playing the chorus at bar 33 gives us:
MacBook Pro
–> 6 groups
ELITE5v2 "Quiet" mode
–> 6 groups
ELITE5v2 "Entertainment" mode
–> 11 groups
ELITE5v2 "Performance" mode
–> 13 groups
Testing Time-to-Insert-a-Track
I added an empty track at the bottom of the set and measured the time it took for the action to be executed using a stopwatch. I repeated every measurement 4 times and took the average. The times to insert an EQ8 or to delete a track are always roughly the same, so I limited this test to inserting an empty track.
Results
We can see from these results that the lag time scales with the complexity (number of groups) of the set. This behaviour is the same for Mac and Windows. The Mac is always slower, which was to be expected due to its slower CPU. The Windows machine is the slowest in "Quiet" mode, and fastest in "Performance" mode. This suggests that the lag time decreases as the CPU speed increases. (Note that none of the computers were able to play back the session without audible dropouts at 16 groups.)
The ELITE5v2 in "Quiet" mode is comparable to the Mac, both in terms of playback performance and sluggishness. In performance mode, it has about twice the CPU performance. However, the lag time is not half as long, suggesting a diminishing return with faster CPUs.
It seems to me that the Mac OS has no inherent advantage over Windows regarding this particular issue. However, it would be interesting to see test results for the M1-M4 Max chips. Those might be powerful enough to mitigate the issue effectively through raw performance.
Inspecting the LOM
It has been previously speculated in [1] that the root cause of the sluggishness is related to the Live Object Model. I had the idea to investigate this further by analyzing the changes made to the LOM by reverse engineering the project file of a live set. An *.als file is essentially a human-readable *.xml file wrapped in a *.gzip file. I opened one of my projects in Live 12.2.1, added one empty track, saved it, and then closed the session. I also compared whether adding a track at the top or bottom of the project would make a difference. Here are the lag times:
Inserting an empty track at the top of the set
–> 5.58 seconds
Deleting the track at the top of the set
–> 5.51 seconds
Inserting an empty track at the bottom of the set
–> 5.28 seconds
Deleting the track at the bottom of the set
–> 5.25 seconds
Then I used 7-Zip to unpack the edited set and the original, and compared the XML files in WinMerge. It reveals something that anyone who has previously played with M4L already knows: Each object in a Live Set has an ID, and in some cases these IDs are assigned in ascendingly order. This means that every time such an object changes its place in the set, when it is added or removed, many other objects change their IDs. Tracks also change their track names to reflect the new numbering (ok, that is not a surprise to any Live user).
When inserting a track, the IDs of warp markers, plugins, and even file references to samples are updated. If this process is responsible for the lag time, then it should take less time to add a track at the very end of a set, since all the IDs that come before that wouldn't have to change. Indeed, my measurements reveal a slight difference of ~0.3 seconds in lag when inserting a track at the top compared to adding it at the bottom of a set.
How to mitigate the issue
Others and I found that the sluggishness is proportional to project complexity and inversely proportional to CPU speed. Reducing the number of plugins used can be achieved by doing as much as possible with each plugin, which means setting compressors and EQs carefully to avoid stacked processing. These are mixing principles that are (usually) good practice anyway! However, this can also involve using plugins that offer a wide range of capabilities within themselves, such as iZotope Neutron and Ozone. (These typically come at the price of higher CPU usage in playback, though.) A long vocal chain that consists of 10 plugins could be replaced with just a single instance of e.g., Neutron or UAD Topline Suite, thereby reducing the number of plugins (but possibly at the expense of higher CPU usage during playback). I highly recommend reading the main post in [1] or [2] in this regard.
Another option, which I have not yet investigated in detail, might be to use a plugin wrapper like Waves StudioRack, Blue Cat's PatchWork, or networked audio on the same computer with tools like AudioGridder or Vienna Ensemble Pro 7. This, of course, comes with its own challenges. Still, it’s an intriguing idea that might help, since it could reduce the number of plugins the LOM has to manage by wrapping longer plugin chains. By routing the audio to a different application via localhost, or even a different computer on a fast network, one might also be able to use the efficiency cores of the CPU despite Live's limitation in this regard. For everyone getting too excited now: I have found AudioGridder to be still quite buggy and not worth the trouble. Vienna Ensemble Pro 7 costs 195€ and is commercial software that should run quite reliably (I haven't tried it yet). Blue Cat's PatchWork costs 99€. In any case, one has to deal with a second program or intermediary plugin that hosts the outsourced plugins, which is not a pretty solution.
Deactivating Control Surfaces can improve the lag time by a small amount. In my tests, I could get about 5% less lag time when I deactivated all the control surfaces. Understandably, these add overhead to the GUI since they need to communicate every change in the set with external devices. However, the small impact they make tells me that they are not the root cause either.
Ultimately, the backend of Live would likely need to be redesigned in substantial ways and to a degree that might not even be possible at this stage of development. Therefore, I would like to suggest new features that could at least mitigate the issue further, based on what I have found out so far.
If we had the ability to freeze group tracks and then actually unload all the plugins and tracks behind the frozen group, this would allow a workflow where one can freeze and unload all the parts of the song that don't need to be worked on at the moment. For example, one could freeze and unload everything except the vocals and then do a vocal session. Later, the rest of the set can be reloaded with a click of a button. Yes, this unloading and loading would introduce some wait times, but it is still better than constantly bouncing between the vocal session project and the track project.
Deactivating tracks, plugins, and devices so that they are fully unloaded from RAM, latency compensation, and the LOM, yet they remain in the session. Then they can be easily reactivated when needed later. This is especially useful when trying out different versions of a song or temporarily deactivating plugins, especially on the master. My experience shows that even bypassed plugins and devices add to the lag time; therefore a deactivation feature might help.
Use efficiency cores on modern CPUs. It has already been discussed extensively in certain threads and YouTube videos (M4 Pro MacBook Pro: HUGE Leap for Music Production | M4 Pro vs M3 Pro vs M2 Pro vs M1 Pro), yet Live remains on the side of DAWs that hesitate to use efficiency cores. However, I think other DAWs are already proving that it is possible and that the e-cores significantly increase playback performance. If the efficiency cores could mitigate the sluggishness issue, Ableton should do it.
The last idea is a wild shot in the dark, because I don't know the exact root cause of this issue or details about Live's implementation. I wonder why the IDs of objects in Live are assigned in ascending order? This makes me think of how DHCP servers assign pseudo-random network addresses to clients, which are based on the hardware properties of the devices. If a device is removed from the network and rejoins later, it typically regains the old pseudo-random IP, and there is no need to update the IP addresses of everyone else. Something similar could be done here, using certain hash algorithms to give objects IDs that never change.
Conclusion
This issue is regularly slowing down my work, forcing me to investigate and find workarounds. Doing such tests and investigations takes a lot of time that is not spent on making music, and it is frustrating. I hope I was able to illustrate that it is a broader issue affecting many users and has existed for a long time.
I have collected 13 different forum posts, most of which are from recent years, with some dating back 8 to 10 years. In the comment sections, people often report the same issues, while others claim not to have this problem at all. I want to remind everyone that there is a vast amount of different genres and styles, each resulting in vastly different workflows and needs. It is possible to make a beautiful song with 20 tracks, and in such a case, you would probably not care. That doesn’t invalidate other artists’ workflows that do result in larger sessions.
To the community:
I would appreciate it if you could verify my tests on your systems. We now have a lot of anecdotal data, but only a standardized test would provide us with more insights into how computer specs affect this. It would be great if we could compile a dataset of varying PC and Mac specs with the playback performance test and the time-to-insert-a-track test. Everyone has the demo set as part of Live 12, so it is repeatable for everyone. You can also download my test set here:
https://www.dropbox.com/scl/fo/w2tawwrut7eqof5dld1ho/AN---NnIU6Ohp75QY-KUSpY?rlkey=48175qtzjotxgy4kwopmzmqsf&dl=0
What I ask from Ableton:
First of all, we need complete transparency on this issue. We need an official explanation why this happens, which system specs are the relevant factors to mitigate the issue (should I get a machine with more RAM, faster CPU, Mac, Windows …?), which live set structures affect this the most (is it devices, 3rd party plugins, racks, sends, non-default routing, specific M4L devices …?) and how do we have to design our live sets and templates to mitigate the sluggishness in general.
We need this issue to be addressed as soon as possible. In my view, Ableton has a history of adding more and more bells and whistles to the product, while neglecting some basics. And while everyone certainly appreciates the new and improved devices, MIDI features, etc., I think, as a DAW, Live should lay the groundwork for an efficient workflow first. This issue certainly affects everyone. Even in use cases where people work with smaller sets, the slowdown is still noticeable to some extent, and while it may be workable, it still costs time throughout a workday. For me, even waiting only a few seconds on something is often enough to get me distracted with other things and break my flow.
Professionals can afford the highest-spec MacBooks, which might mitigate the sluggishness with their incredible performance. However, as my tests suggest, increasing CPU performance has diminishing returns, and I would guess that the primary user base of Live is not making a living with their music and cannot justify spending the price of a small car for the latest MacBook Pro. Especially, new customers are going to be folks with older and weaker machines. Beginners are also prone to over-processing tracks and often lack the experience in building a session effectively. (I have been there.) Therefore, solving this issue should be of keen interest to Ableton, not only to stay competitive in the DAW market, but also because it jeopardizes Ableton's mission of enabling everyone to be creative. The first sentence that describes Live on the Ableton website reads:
"Live is fast, fluid, and flexible software for music creation and performance."
Let’s make this ambition come true!
Thank you for reading all of this! I highly appreciate your attention!
Yannis
References and Similar Reports
A Quest for Optimal Ableton Performance
[1] https://forum.ableton.com/viewtopic.php?t=245600
[2] https://www.reddit.com/r/ableton/comments/w8w2mg/a_quest_for_optimal_ableton_performance/
Why is adding/removing plugins/lanes/effects so slow?
[3] https://forum.ableton.com/viewtopic.php?t=250913
[4] https://www.youtube.com/watch?v=RwaDpyV-Y5A
Largeish projects feeling quite slow. Is it my computer or is Live just poorly optimized on windows?
[5] https://www.reddit.com/r/ableton/comments/1fjg5mm/largeish_projects_feeling_quite_slow_is_it_my/
Ableton Live 10: What makes all basic actions in big projects slow? Is there a work around?
[6] https://www.kvraudio.com/forum/viewtopic.php?t=547391
Ableton slow despite performing PC.
[7] https://forum.ableton.com/viewtopic.php?t=249770
Why is my Ableton Live super slow on a pretty good pc? (Windows)
[8] https://www.reddit.com/r/ableton/comments/1emzo6q/why_is_my_ableton_live_super_slow_on_a_pretty/
Why are large projects slow regardless of actual CPU/Ram load in Ableton?
[9] https://www.reddit.com/r/ableton/comments/qygyz1/why_are_large_projects_slow_regardless_of_actual/
Ableton laggy with low CPU usage
[10] https://www.reddit.com/r/ableton/comments/13sfxtn/ableton_laggy_with_low_cpu_usage/
Ableton getting ridiculously slow What can I do?
[11] https://www.reddit.com/r/ableton/comments/1e6os21/ableton_getting_ridiculously_slow_what_can_i_do/
Ableton 12 is a mess and i wish the developers would listen to us
[12] https://www.reddit.com/r/ableton/comments/1cta04v/ableton_12_is_a_mess_and_i_wish_the_developers/
Live is super slow moving/adding/deleting tracks + plug-ins, etc. with 20-30 tracks
[13] https://www.reddit.com/r/ableton/comments/7jar0w/live_is_super_slow_movingaddingdeleting_tracks/
What makes large Ableton project files run slower?
[14] https://www.reddit.com/r/ableton/comments/7hok77/what_makes_large_ableton_project_files_run_slower/
My Ableton Live is lagging
[15] https://gearspace.com/board/music-computers/1031604-my-ableton-live-lagging.html
