Live no longer stable . 'out of memory' issue outstanding

[wilsonrx]

I think crash reports are there to make you feel better; its the same deal as when Windows has an issue and you send the report to Microsoft.

Its like those buttons on pedestrian crossings that don't actually do anything but make you feel better because you can push it. We are those people that push the buttons rapidly hoping it makes us cross the road quicker!

[wmayhem]

I am experiencing the Out of Memory error several times per session now with 8.2.2 using the same plug-ins as I did with the previous version of Live. WindowsXP 32Bit (4GB RAM - and yeah I know that only 3GB is addressablein XP 32bit)...

Ableton Help!

[ctgarvey]

Update: I hoped that 8.2.2 would be more stable than 8.2.1 but sadly no. 5 crashes in 10 minutes;

22/04/2011 23:16 13,495,704 Ableton Crash Report 2011-04-22 231637 Live 8.2.2.alp
22/04/2011 23:20 13,732,657 Ableton Crash Report 2011-04-22 232015 Live 8.2.2.alp
22/04/2011 23:22 13,787,722 Ableton Crash Report 2011-04-22 232230 Live 8.2.2.alp
22/04/2011 23:26 13,859,815 Ableton Crash Report 2011-04-22 232602 Live 8.2.2.alp
22/04/2011 23:29 13,866,888 Ableton Crash Report 2011-04-22 232844 Live 8.2.1.alp

recap; moved to win 7 64 bit dedicated music computer in an attempt to provide more stable platform
with more memory access. Ableton 8 consistently crashes with Native instruments.
most notably reaktor - the finger or - the mouth. Also with kontakt 4 - scarbee guitarist.

in fact i had almost lost a months work because 8.2.2 would no longer even open the file without crashing so i had to
hide the 'offending' vsts (kontakt 4 latest & reactor 5.5.1). i was then able to get into the file and delete the tracks.
I use a lot of sample libraries which use a lot of RAM, but my executive summary of Live 8 is:

Live is no longer fit for purpose. Its key strength for me used to be reliability. Gone after Live 7.
If you are doing any form of heavy sample bank / orchestration stuff, find yourself a new package and save yourself the stress of burning your timeline on this package. Its true I dont know if NI are at fault here, but they work fine in standalone mode.

[ctgarvey]

Ive been on windows 7 64 bit / 24 Gb of Gigabyte approved RAM / intel i7 UD3R Gigabyte board / SSD bootdrive, RME Fireface 800, Marvell RAID0 SATA 6Gb/s (2 x seagate barracuda 7200RPM / 64Mb cache) for audio now for 9 months.Basic 6600 nvidia geforce dual head video card. PC is music studio dedicated (no games) and isolated from internet, and very stable. ie close to the ideal most stable box for PC audio.

Stability report;

I would have to say live appears more stable on win 7/64 bit than on XP though I am on better hardware so I'll never know for sure. They have still not fixed 'out of memory' issue however.

I rendered ALL vsts, effects etc everything to 32 bit wav, dithered to 16bit wav and hit 'out of memory' crashes
with approx 400 samples loaded. Some hard memory limit was reached and it was precursored with 'disk overload' warnings.
In the end, I had to purposely hide samples in order to get back into the live set as it was crashing live even on startup with the ' a serious error has occurred' message etc.

Arrangement view
Limit reached with approx 120 minute set with :
32 audio tracks or audio clips in 6 groups - not all tracks accessing the disk all the time. estimate 30% of the arrangement timeline for these tracks had active wav clips. All wav files / clips in set are stereo 16bit 44.1Khz.

7 further audio tracks consisting of the above tracks rendered ie continuous wav files accessing disk for entire duration of the set. These were the source for all the session view clips.

Session view;
approx 7 tracks x 90 scenes x .8 (80% loaded with clips) = approx 500 clips. -

The system was rock solid stable with no clips in session view.But thats of no value to me for live performance, so I started the process of copying useful remix clips from arrangement to session view.

Live 8.2.5 started with the disk overload feedback around the 300 clips mark and necessitated system reboot etc..

The only way I can continue now is to 'hide' all the audio samples in the grouped support tracks, so that Live wont find them and crash upon loading the set.

I'd like to know more about how live stores wav clips when copied from arrangement to session view. I would hope they dont duplicate the file but simply store a pointer to a position in the arrangement view file and maybe cleverly stores the start of any clips in memory.I'd also like to know what live is doing when it boots and says opening 400 samples etc, then buffering 400 samples..And if buffering, is there any way that buffer size can be modified? - Or maybe some 32bit to 64 bit thunking add on to get at 64bit OS RAM?


I dont know what Abletons position is on 64bit but they need more application RAM. Reaper is 64bit but is arrangement
view style only and I want the close integration between arrangement & session view.The immediacy of session view is the one competitive advantage Ableton has got.I cant see Rewire ever aspiring to capability of fully integrating Reaper (for eg) with Live such that you can paste audio between the 2, and swap between each view without missing a beat via transport bar. I CAN see someone writing a VST plugin for Reaper that emulates Ableton session view and talks to APC20.
Im tempted to say if Ableton dont get their act together and go 64bit, I'll do it myself.
HAL Automaton

[ctgarvey]

I got a helpful reply from support on the subject;

thanks for sending us your crash report and sorry to hear that Live causes problems for you.

We know well about Live's out of memory behavior. Live can use up to 4 GB of memory on 64 bit systems, but doesn't know how much of this memory is already filled. If this limit is reached or exceeded by whatever action, Live wouldn't inform you, but simply crash. It's high on our list of annoying issues and at some time, we'll address this and see what can be improved. This wouldn't be something you do casually, however, so it's not yet clear at the moment when we'll do this.

Besides working with an extremely large number of clips or enabling RAM mode for the audio clips, working with large sample libraries is one of the main reasons to fill the memory quickly. If you then do any editing operations on clips and tracks or add more samples or devices, a crash might occur.

When working with lots of sample libraries, a workaround to prevent crashing is to freeze and flatten tracks that contain multi-sampled instruments. By freezing, only the CPU gets discharged, but the memory-consuming devices and libraries are still kept in the background. When flattening such track, the track will only contain the frozen audio file, while devices and samples get removed.
If a set can't be loaded anymore because it's to heavy on the memory, you can open it in Live's browsers, import the single tracks into a fresh set and flatten them here, so you can finally save a new, less memory consuming set.

Regards,

Torsten Wendland
Ableton Technical Support

[MusicIsMath]

Can only use 4gb in 64bit win7 >..< Wish I had seen that before I stumped for the extra ram to take it up to 8gb lol.

Out of curiosity, what sort of lengths are the clips you are using?
I'm about to take ableton out tomorrow on the new lappy (providing I can get it all installed and create some set templates for current tracks) I doubt I will be using anything that is longer than a couple of seconds per clip with some follow actions here n there.

[ctgarvey]

clips vary in length from 1 s to 32S with average being 4 bars @ 120BPM or 8S. I dont have any clips using
the 'ram mode' option.

[loydb]

I'm also trying to do Ableton projects with a ton of orchestration -- it takes 10 minutes to load one project because I have to keep clicking 'yes, load, I know it might destabilize my system.'

When we started bitching about 64-bit support a couple of years ago, Ableton's apathy was quaint. Now it's just pathetic. I'm migrating everything over to Cubase, since Ableton clearly has no interest in being a modern composing workstation.

[jpodtbc]

thanks for posting your reply from tech support. as i suspected, it's now clear (and utterly frustrating and extremely disappointing) that ableton has chosen not to prioritize stability. multi-sample libraries are only becoming larger and more common. this means more annoying crashes for all ableton producers using them.

[friend_kami]

would be better if they simply retracted the ability to use plugins and first and foremost made live able to utilise all avilable memory on the machine, including knowing how much memory is avilable, and how much is in use and/or put aside for other applications.

then, if they magically manage to actually do that, then they should release an update which allows live to use plugins again.
at the least this way we might actually have some sort of indication when live decides to randomly crash on us.

in other news: what the hell is the point of this forum unless the support is here?
theorycrafting users?

also more: how the shit do you get in touch with the support anyways?
i've sent to many bugreports it's not even funny, and i've yet to get a single personaly reply. i do get that automatic reply, and i am sending them to the sam adress that live tells me to send it to after "recovering" from a crash.
is that the wrong place?

[adamri2010]

Hi guys,

I am also using win 7 64bit with orchestral vsts... Trying now to tackle the problem (low memory crash) and have found that running the [vst software].exe in different compatibility modes stops these messages. [[[[ to do this right click, select properties, click compatibility tab ]]]]. THIS WORKED for East West Symphonic Gold and also for East West Choirs. Have not yet further looked into this but do suspect it may also have something to do with the way windows 7 >4gb memory modules work within the OS. Am going to muck around a bit with the bios settings tonight and will post later what I find...