Ableton - max .als size that triggers "not enough memory..."

[swivet]

I'm just curious as I seem to be reading quite a few posts about this whole "there is not enough memory...please save and quit" message and everyone seems to have plenty of memory, so is this something that we can expect to be fixed in the next update?

I just want to know if Ableton mods can speak on whether you've had any luck diagnosing this. Since Ableton 7 didn't have this issue with even larger .als files I know the software can be made to avoid this but can you guys give us any info as to your luck with the diagnoses? (i.e. you think we will be able to open sets in 8.0.2 that we cannot in 8.0.1)

I just don't want to continue throwing time down the drain starting over after I lose all my work from every crash if I can open these sets in the next update. Any info would be really appreciated as I've now wasted 15+ hours just redoing work and then losing it all over again when Live 8.0.1 crashes and repeats this error. Thanks guys.

[swivet]

Just a bit of information if it helps further diagnose the issue:

A 160.1mb .als will NOT open in Live 8.0.1 and gives the memory message.

A 142.6mb set WILL open in Live 8.0.1.

Hope that helps...

[moonyblue]

Funny I had this problem too along with an audio issue. The audio issue was my fault as I had a delay looping to inf on a plugin synth but the memory and CPU probs I get are still affecting the work flow.
I'm on a Mac pro Quad core 4Gig Machine, plenty of power for most applications. In 7 I can use a lot of plugs and effects without a hitch.

With Version 8, So far I have updated the operating system, deleted all demo plugins and any other plugs which gave problems in 7.
I have run a repair library scan and rescanned the plugs, cleared the cache in the Pref settings & checked my log files and have so far been able to load all the files that crashed including some that crashed a long time ago in 7.
Time machine is off, airport is updated and off. I gained a bit more CPU power but the glitches are still there, which plays havoc with any quick work like grabbing live loops and dragging audio clips etc from the library.

I find it very hard to believe that that we just haven't got enough memory for this 8 version so, Next I'm turning off multicore use in the Prefs, then I will start looking at how duplications of channel strips, plugs and settings are handled and will change the cache for extra space.
I'm starting to think that most of us multicore users are suffering from duplication issues in the way live 8 uses the 2 cores but I may be wrong, I'm no expert. I am sure the Abe's will be sorting it out it's just a bitch that we have to wait for the updates whilst trying to work out whats going wrong. Might be better to carry on using 7 for a little while longer.
FWIW I would like to see that CPU load right back down, close to 7s reputable standards.

[swivet]

Oddly enough I haven't really had an enormous hike on CPU usage at all. It's actually right on par with 7 in that respect. It's just that "there is not enough memory..." message on startup and the inability to open sets that opened no problem in 7.

On another note, Just dumped another 8 gigs of RAM in this thing today so 16GB total now and it still gives that memory error. So I'm really hoping if we continue to post stuff that Ableton will be able to diagnose this and fix it for 8.0.2. I dread the next crash like the plague because I know if it happens I will lose everything I've done since none of the 10 new versions will open I'm sure. I won't even quit this project right now for fear of getting the memory message.

[swivet]

So it looks like the max .als size Live can handle is somewhere between 142.6mb and 149.7mb because 149.7mb .als file will not open but a 142mb file will. ABLETON COME ON!!!!!

[friend_kami]

ive recently starting to get this too and im pretty sure that ive narrowed it down to using looper.
ive got this rack set up with 3 loopers that always records one bar of audio on every scene launch, but after some 3-4 hours using this setup i get this error. when running live otherwise i dont. only when i use looper for long periods of time. or several loopers.

[swivet]

Sorry friend_kami I only work in arrangement view so I can't speak on session. But what I do know is that as soon as the file size gets above whatever the magic number is between 142-149mb, the .als will not open in Live 8.0.1 no matter what. This should be a MASSIVE CLUE to Ableton in fixing this.

[Gurulogic]

It doesn't matter how much ram is in your computer, a 32 bit application can only use about 3.5GB physical ram and about 4GB virtual memory. If it is this wall you are hitting while opening your projects, I doubt it has to do with the size of your .als specificly, but instead it would probably be the requirements of the contents of the file that may be causing a spike in ram / virtual memory while opening the file.
I do agree that IF this is the case, then Ableton ought have sort of protection in place that would prevent you from saving a file if it could exceed the 32 bit memory limitations during load...

[arachnaut]

I just loaded an ALS file (in Live 8 arrangement) that is 988kB with no trouble. Load time was also quite fast. It had over 1000 smallish samples on one track.

The situation may be more complicated than you think, because the ALS file contains pointers to sample data, not the data itself.

Not all of the data needs to be in memory, especially in my example. But if had a real large sample in the start position, Live might pre-load that in memory and run out of memory. Or if I had a lot of tracks - all the first samples may get pre-loaded.

I have notice one live set loaded in Live 7 but not in Live 8, but this was about 2 GB in size - right at the limit, and Live 8 is a little larger than Live 7 in resident memory footprint.

[swivet]

I just loaded an ALS file (in Live 8 arrangement) that is 988kB with no trouble. Load time was also quite fast.

That's a really small file - under a megabyte - so I would expect it to load super fast. I just find it odd that I can't load sets above the range I specified in the last post. This is consistently the case for me. Those are the magic numbers in my case on a Mac Pro and a MacBook Pro. Seems like it would differ from computer to computer but it's the same on both.

[do_om]

I get this error with a 532kb .als file.

Another that wouldn't load was around 800kb.

Both very "light" projects. I managed to get one up
and running by toggling the audio driver and then
removing a selection of plug-ins, then resave the thing.

Lost alot of work but at least I can load it up and
rework the track as there are deadlines to meet.

[S4racen]

I get it when my set length nears an hour, if i delete the loopers i have in a rack the problem goes away....

Cheers
D

[arachnaut]

I just loaded an ALS file (in Live 8 arrangement) that is 988kB with no trouble. Load time was also quite fast.

That's a really small file - under a megabyte - so I would expect it to load super fast. I just find it odd that I can't load sets above the range I specified in the last post. This is consistently the case for me. Those are the magic numbers in my case on a Mac Pro and a MacBook Pro. Seems like it would differ from computer to computer but it's the same on both.

Yes, sorry - brain fag on my part - kb is much less than mb

[[nis]]

Hello,

it's hard, if not impossible to say what the maximum possible size of a Live set can be, as the RAM load depends on many different factors. Obviously, the RAM is full as soon as the RAM is full. Some things which can lead to an enourmously high RAM loads (just out of my head) are:

1. Too many clips in the set (the sheer existence of a clip costs a certain amount of RAM, regardless of its type, length or content). If you have hundreds of clips in your set, this will sum up to a considerably high RAM load. If that's the case in your sets, I'd highly recommended to consolidate as many clips as you can.

2. You use a lot of sample-based devices or plug-ins in the set. This goes at the cost of RAM resources, especially if there are many samples used in the preset and if that track is armed for recording / monitoring is on.

3. There are many locators in the Arranger. Live needs to create a buffer for each locator per audio track and this is stored in the RAM. That's necessary to avoid dropouts when you jump to a locator. Many locators + many audio tracks = high RAM load.

4. Too many clips are loaded into the RAM (via the "RAM" switch). Same goes for Sampler presets.

There are surely lots of other reasons for high RAM loads, but the aforementioned things are the most overlooked ones.

Just a bit of information if it helps further diagnose the issue:

A 160.1mb .als will NOT open in Live 8.0.1 and gives the memory message.

A 142.6mb set WILL open in Live 8.0.1.

Hope that helps...

Are you sure that these are the file sizes of the actual .als files? If so, then your sets will most likely contain too many clips. Or is that the size of your entire project folder (i.e. incl. all audio files, etc.)?

On another note, Just dumped another 8 gigs of RAM in this thing today so 16GB total now and it still gives that memory error.

This won't help anything at all. The maximum address space for 32-bit applications is 4 GB. There's no way to use more than that. Mac OS X users are even on the lucky side because OS X can address the full 4 GB to an application. Windows users can only use 2 GB (or max. 3 GB if the so called "/3GB" flag is set in the boot.ini file). Note that this is a limitation in the OS, not in Live. The only solution to use more RAM would be a 64-bit Live version running in a 64-bit OS. There is currently no 64-bit Live version available.

I'm just curious as I seem to be reading quite a few posts about this whole "there is not enough memory...please save and quit" message and everyone seems to have plenty of memory, so is this something that we can expect to be fixed in the next update?

I can't say much about that yet. I wouldn't rule out that there's something wrong with the memory management, maybe there's even a memory leak somewhere. We need to be able to reproduce this here before we can fix anything. As far as I know, one of my colleagues is already in touch with you regarding a bug reporting .alp (aka event recording), correct?

Best,
Nico

[swivet]

Hello,

Are you sure that these are the file sizes of the actual .als files? If so, then your sets will most likely contain too many clips. Or is that the size of your entire project folder (i.e. incl. all audio files, etc.)?

Yes, this is the actual .als file size, not the project file size. The project file size is massive because I have to save a copy every 2 min and keep it under that range or else it won't open due to the memory message. Out of a total of 53 copies of this set, only the ones below that magic number in the 142-149mb range will open (and they actually open relatively fast compared to Live 7).

1. Too many clips in the set (the sheer existence of a clip costs a certain amount of RAM, regardless of its type, length or content). If you have hundreds of clips in your set, this will sum up to a considerably high RAM load. If that's the case in your sets, I'd highly recommended to consolidate as many clips as you can.

2. You use a lot of sample-based devices or plug-ins in the set. This goes at the cost of RAM resources, especially if there are many samples used in the preset and if that track is armed for recording / monitoring is on.

3. There are many locators in the Arranger. Live needs to create a buffer for each locator per audio track and this is stored in the RAM. That's necessary to avoid dropouts when you jump to a locator. Many locators + many audio tracks = high RAM load.

4. Too many clips are loaded into the RAM (via the "RAM" switch). Same goes for Sampler presets.

There are surely lots of other reasons for high RAM loads, but the aforementioned things are the most overlooked ones.

It is not uncommon for me to have upwards of 130 tracks, all with effect presets on them. That's why I invested in the computer I have because it rocked with Live 7. Everything was solid. I understand all the logic behind consolidating and I do consolidate as much as possible; however, the fact remains that Live 7 never even ran into even the slightest hitch with .als sizes wayyyy higher than 149mb.

We need to be able to reproduce this here before we can fix anything.

I have duplicated this on 3 Mac machines now - anything above that specified range will not open on the Macs I've tried and delivers the message. Perhaps I'm just lucky

One odd note - if I have the options.txt file for creating the bug reporting folder placed in the Live 8.0.1 pref's folder, then these large sets will sometimes open briefly after about 6 min or so and display the bug report window, but then immediately crash. If I remove the options.txt from the folder then they will simply deliver the memory message and not open (or crash after a period of time attempting to open). So the options.txt file being in the folder can assist in opening the set, despite it crashing immediately. But hey, at least it opens for a few seconds, which I hope can be of help to you guys.