Ableton Forum

too lazy to explain my point but it's not really relevant to the issue anyway.
hope there's some solution to it on the horizon.
Live's working rock-solid on my amd 3500+ here...

Question : how much RAM do you have ? I think this is very important.
Monitoring with Activity Monitor seems to lead to Josh's conclusion : during a long Live session memory's not released and drains to … almost no memory left, even with a 2 gb ram Macbook Core 2 Duo. That explains why closing the set's not enough and a restart of Live's necessary.

Meanwhile adding RAM seems to solve the problem (so far, I'm very cautious after my screwed up gig last week )

BTW Amaury did answer me in a related thread :

http://www.ableton.com/forum/viewtopic.php?t=57148

mocker wrote:Question : how much RAM do you have ? I think this is very important.
Monitoring with Activity Monitor seems to lead to Josh's conclusion : during a long Live session memory's not released and drains to … almost no memory left, even with a 2 gb ram Macbook Core 2 Duo. That explains why closing the set's not enough and a restart of Live's necessary.

Meanwhile adding RAM seems to solve the problem (so far, I'm very cautious after my screwed up gig last week )

BTW Amaury did answer me in a related thread :

http://www.ableton.com/forum/viewtopic.php?t=57148

Thanks, replied there as well

.

I'm having the same problem as well I think. It's doesn't seem to be exclusively about MACs or core2duo's s...

1.7ghz Pentium M (centrin) Dell D800 with 1Gb Ram 80Gb WD Scorpio (5400rpm) Echo indigo DJ (PCMCIA) , MIDIsport 2x2(USB) , Optical mouse (USB)

Like many people on this board I've tried all the usual fixes - background services, higher latency settings, power scheme always on etc.. The system is seriously stripped down. The glitches only seem to occur after about an hour or so of playing, and only stop when Live has been re-started -not exactly convenient when you playing in a club..

I've even tried the PCI latency tool and Prio.exe (application priority). Didn't make a scrap of difference.

Josh Von wrote: It says the clip is still being used in your set, when its not.

This is also true of sampler,if you create a sampler preset,save then delete from the set,if you then try to manage the preset live informs you that the sample is in use when it's not,meaning you have to close the set to manage sampler presets, inconvenient

Live also disappears/closes for me if i leave it running without using it.

I post this not to be a nay-sayer, but to try to help figure out what's going on.

I've done some testing today to try to recreate some of this behavior, so I just did a bunch of duplicating at various grid settings and then some copy / paste to expand the arrangement.



Each "block" of clips towards the bottom amounts to 1,404 clips. Playing this is at the absolute limit of my system. CPU meter goes to approx 70% and many disk overload indicators. It will play though, but with the expected loss of responsiveness and bad screen redraws.

Then consolidated all that...



This brings back an immediate return to semi-decent operation - about 38% CPU, but still with some disk overload lights, but no dropouts.

asus p4p800dlx
p4 2.6c SL6WH
2x 1024 pc3200 ddr
2x 80g seagate 7200rpm P-ATA
1x 250g WD 7200 rpm S-ATA
aardvark lx-6
xp pro (no service packs)

Buffer @ 512 samples although I actually seemed to not get much worse performance @ 128 samples. (?)

This is with instant mapping active for an Oxygen8 and remote enabled for a BCF, but not in Mackie mode... I suspect that the performance would be significantly worse with a controller in Mackie Mode, maybe that's the next thing for me to test...

And I should also add that I spent some time watching the Task Manager while alternating between pasting and deleting large blocks of clips -


I actually saw very predictable behavior, meaning that pasting a large block would eat up some RAM, but then deleting it would bring it back down to the same exact RAM amount as before... And that continued time after time.

BTW on those screenshots my total RAM used by Live was pushing 700Mb,

so I must ask - Josh do you think 1G of memory is cutting it on your system? I think it could be choking it

longjohns wrote: so I must ask - Josh do you think 1G of memory is cutting it on your system? I think it could be choking it

Yes I definitely think another stick of RAM will help, but not completely address these problems.

1 - Look over the three largest threads in here this week: Audio Dropouts, Juddering etc ... and note how many people that cant work have 2 gigs or more of memory.

Also note how many of them (including me) are running a lot less clip edits than you show on your screen and have the same issues.

also:

2 - If 2 GB is the minimum requirement to comfortably produce full sized production tracks in Live, than as I said earlier Ableton should come to terms with this and be open with thier customers about it imo. Up the official minimum requirements.

Here's something interesting I discovered last nite (along with something else that I will start a new thread about):

Here is a screenshot of my current set, 52 tracks of straight audio. At this point the set has been bounced again using Render All Tracks at the master.

There are no effects in the inserts, sends or master. All I am asking Live to do is play straight audio clips in beats mode (one marker at the beginning of the tracks arrangeview, and nothing else.

No effects, no envelopes, no splits, nothing. I dragged the stems back into a fresh set




Here is what Im asking Live to play for the intro.



MORPH, MCHA, MCH B channels are simple 8bit like glitchy type sounds, nothing taxing. But also note that the rest of the channels have clips with no data playing at this point,

I havent cut off the silent portions of the clips. So there are 49 tracks with clips with essentially no data at the intro

To show a bit of this:




Now, guess what happens when I hit "play" on this set the way its illustrated. Live chokes. I get a red hard disk light and a bit of sputtering at the start ... i can hear something trying to come through but its not happening.

Why?

What is it about the design of this program that it cant look at this set and say "here are lots of audio clips, but most are empty data. Let me play the audio where there is data, and ignore these long sections of empty clips where theres nothing to do"

It doesnt do that. This is the kind of thing Im talking about. What does this point to insofar as how Live might be handling clip data in other, more complex areas?

Its not a good sign. Extremely inefficient imo and I think this kind of thing is the root of all these problems in one way or another

.

Josh Von wrote: What is it about the design of this program that it cant look at this set and say "here are lots of audio clips, but most are empty data. Let me play the audio where there is data, and ignore these long sections of empty clips where theres nothing to do"

It doesnt do that. This is the kind of thing Im talking about. What does this point to insofar as how Live might be handling clip data in other, more complex areas?

Its not a good sign. Extremely inefficient imo and I think this kind of thing is the root of all these problems in one way or another

.

Hi Josh,

I understand what you're saying, what you're expecting. And I know that you know that you here have a simple problem of hard disk overload.
But the kind of 'feature' you are asking for is kind of counter productive, I feel. How much processing would it take for a software to determine if it should ignore a track because it is silent? At which rate should it check, not to miss the first bit of sound? What about the treshold?

Are you aware of any software able of this? I think that it makes no difference if an audio file is silent or not for a software, it has to be read from the hard drive, and to change this would need some serious and CPU expensive algorithm.

A feature like the 'strip silence' from Pro tools is more what you are after. It is an offline process and I don't think we'll have that any time soon, but I think that is what would make the more sense. Don't you think? Time for the wishlist!

Regards,
Amaury

Amaury wrote: But the kind of 'feature' you are asking for is kind of counter productive, I feel. How much processing would it take for a software to determine if it should ignore a track because it is silent? At which rate should it check, not to miss the first bit of sound? What about the treshold?

Hi .. no, I wasnt implying that we need a feature to address this by stripping data. Very easy in Live to just CTRL-E split delete or drag clip ends.

I was using this as an illustration that might be pointing to how clip data is handled by the software. I dont have any of the other DAWs installed anymore, but I would be really interested to see how they would handle the exact same scenario:

Load out the channels with thier equivelant of clips, mainly empty of data and see how they handle it.

As I recall when I had Cubase installed on here - number of clips (by itself, regardless of amount of actual audio data represented) and configuration on the grid didnt have this much impact or cause this many problems.

It just didnt seem to be a showstopper

.

My experience was that this stopped for me once I maxed out my RAM to 2GB from 512MB...

Josh Von wrote:nothing taxing. But also note that the rest of the channels have clips with no data playing at this point,

I havent cut off the silent portions of the clips. So there are 49 tracks with clips with essentially no data at the intro

The computer doesn't know the difference and is working just as hard to stream all those zeros as it does at any other point in the .wav.

You should definitely trim off all the silence on every clip. Even if you drag the ends on the clip, you've still got many Gigs of blank .wav's clogging your HD

mainly empty of data

They are not empty. They are chock full of zeros, which take up just as much space as 1's

Josh Von wrote: 2 - If 2 GB is the minimum requirement to comfortably produce full sized production tracks in Live, than as I said earlier Ableton should come to terms with this and be open with thier customers about it imo. Up the official minimum requirements.

Agreed.

longjohns wrote:I suspect that the performance would be significantly worse with a controller in Mackie Mode, maybe that's the next thing for me to test...

Did this, and it seemed to not make a difference, which surprised me a bit. I know that sometimes my controllers go out of whack somehow and dramatically slow the system down until they are power cycled and the Live preferences reset.

longjohns wrote:
You should definitely trim off all the silence on every clip. Even if you drag the ends on the clip, you've still got many Gigs of blank .wav's clogging your HD

mainly empty of data

They are not empty. They are chock full of zeros, which take up just as much space as 1's

Yes I know this, using the issue to illustrate the point.

Does Cubase / PT do this when you stretch single (forget what cubase calls thier clips) elements down the grid?

What would happen if you took my same data and represented it there? Would the app lock up and / or PHTTHHH-KKKK-TTTZZZT with the audio?

.