Avoiding Out of Memory crashes in 32-bit

  • Live Versions: Live 32-bit
  • Operating System: All

The 32-bit version of Ableton Live can use a theoretical maximum of four gigabytes on Native 64-bit systems. Because of the overhead of the operating system and other system components, 32-bit applications have a practical memory limit that is somewhat lower; usually between two and three gigabytes.

In previous years, computers had considerably less physical memory than the 32-bit limit. In order to make it possible to use applications with large memory requirements, operating systems would frequently swap data between the (fast) physical memory and the (much slower) hard drive. As memory usage increased, performance would decrease so severely that the user would never actually approach the 32-bit limit.

Due to the increasing availability of 64-bit operating systems and inexpensive RAM, modern computers now often have more physical memory available than the 32-bit limit. As a result, data is rarely swapped to the hard drive, and the computer remains responsive even if the 32-bit limit is approached. But once an application actually exceeds this limit, it will crash.

Use the 64-bit version of Live to avoid these crashes

We recommend using the 64-bit version of Live on machines with a 64-bit operating system and more than 4GB installed memory. On machines with 4GB memory or less, or on machines with a 32-bit operating system we recommend using the 32-bit version of Live. Read here for more information on 64-bit vs. 32-bit versions of Live

Recommendations for dealing with Out of Memory crashes on the 32-bit version of Live:

What uses up the memory?

  • Live devices or 3rd-party plug-ins that use lots of samples are very memory intensive. Ableton's Latin Percussion is a good example, but also plug-ins like Omnisphere or Kontakt when used with large sample libraries.
  • Enabling clip RAM mode loads the audio file referenced by a clip into the memory instead of reading them from disk in real time.
  • An extremely large number of clips might also lead to problems, even when the RAM button is not enabled.
  • Besides those data, all other processes by Live and the operating system need memory.

Why do 'Out of Memory' crashes occur?

  • Live doesn't know how much of the memory reserved for its operation is already filled. With the scenarios described above - having RAM mode enabled for too many audio clips and/or working with large sample libraries, it's very easy to reach the limits.
  • Now, performing any action in Live that needs more memory than currently available might result in a crash. These actions could be:
    • Editing operations on clips and tracks (e.g. Copy, Cut, Duplicate)
    • Adding more samples
    • Adding devices or presets

Live Set RAM optimizations and workarounds

  • Flattening tracks that contain said memory consuming devices frees up memory.
    • First, freeze the tracks.
    • The Flatten command then replaces any original clips with the audio files created by the freezing and then removes the devices and the samples from the Set.
  • If a Set containing memory consuming devices already crashes on loading, it can be restored like this:
    • Open an empty Live Set.
    • Locate the problematic Live Set (*.als file) in Live's browser.
    • Unfold it by clicking the little arrow on *als file - all the tracks contained in this Set are shown now.
    • Import one track of the Set via double click or drag'n'drop into the empty Live Set.
    • Now, freeze and then flatten the imported track.
    • Proceed with the next and following tracks.
  • If a Set containing many (large) audio clips with enabled RAM mode crashes on loading, it can be restored like this:
    • Open an empty Live and unfold the problematic Live Set in Live's browser as described above
    • Import a track containing clips via double click or drag'n'drop into the empty Live Set.
    • For all audio clips, turn the RAM switch in their Sample display off.
    • Proceed with the next and following track.
    • Save the new Set.