Wondering why project file jumped from 10 to 110mb (8.1.4b2)

[massenmedium]

May or may not be related to using the beta of course but it has happened since I started trying it.

I think all I've added other than some arrangement work is a Simpler playing a <500Kb sample and some Ableton effects.

It also takes a really long time 'thinking about things' when saving.

Any ideas?

[Angstrom]

I'm assuming you accidentally activated an audio record somewhere along the line.
why not "manage project" and see what's lurking.
Or just navigate to the project folder and rummage around in the audio folders there

[massenmedium]

Thanks.

It's the actual .als project file though.

[massenmedium]

So what I mean is I can't see why the .als file has increased in size by 100mb.

And it does take a couple of minutes 'thinking' to save!

Just wondered if there were any known causes for something like that.

Cheers.

Edit - one possibility : I did delete a Looper and I wonder if it left something behind...

[Angstrom]

I don't actually know where the looper stores its temp loops when they are cached out of memory
I would have guessed they would be saved on disk as waves in the project/samples/ folders. But a quick look around and it seems they are not.

IMO it would be a bit odd to store them permanently in the .als file, as .als tend to store note, pattern and automation data, but perhaps your guess is correct here (that the .als has the old looper wave).
Only an Abletonian can confim/deny this.

best to send them a mail at [email protected], and link this thread. They may ask you for the .als , so start looking for a dropbox type solution.

[massenmedium]

OK, so.

Clearing the arrangement reduced the file size from 100Mb to under 1Mb! So clearly it was something in there.

I went through deleting the content of each track until I found the one that was accounting for 109Mb in arrangement data. This took quite some time.

What it seems to have been caused by is that in places on that track I'd done some rapid follow action chopping between clips pointing to a couple of quite long files (20-30mins). The chops were 1/16ths. I've done this sort of thing before so still not sure why it should be generating such stupid amounts of data but at least I know where the problem was and can maybe flatten that track for now.

Don't know if it's a bug exactly but the amount of space this arrangement editing was taking up does seem disproportionate and it did seem to be making everything a bit slow and unstable, not to mention taking five minutes or so to save and load.

Thanks for your input Angstrom.

[ton]

Well, if you cut/split especially longer midi clips into shorter parts, Live has the "speciality" of keeping the original clip length and just setting the looping points accordingly, so you need one more step to throw away the unlooped parts, which would reduce your file size again.

In short after splitting midi clips (ctrl-e) you should also consolidate them (ctrl-j), both sides of the rests.

[massenmedium]

Ton, they're not MIDI clips, they were audio clips. And as we know, audio clips are basically pointers to the audio file. I can't realistically, and don't see why I should have to, crop each little clip when I am using features that as I see it are very central to the whole idea of Ableton Live.

Thinking about this a little further what I think is causing the problem, and is likely related to the memory problems people have been seeing with Live 8, is this -

it's those little grey transient markers.

In the case here my original audio files were relatively long (maybe 30mins or so) and so incurred quite a lot of transiemt points. In the old warping scheme I would have just left a couple of markers in the whole file. In the new scheme all those grey markers were in there, even though I'd only enabled two or three actual warp points. Presumably what was/is happening is that those hundreds of transient point markers are being replicated in each little clip.

Does Live need some sort of 'ghost' clip system for where the transient/warp point data in a clip is unchanged from it's parent clip? I know some people would like to see this as an option for the way session and arrange clips interact.

Can I delete the grey markers from the original clip? I'll give it a go - the new warping scheme is still a bit new to me so I haven't done this as a course of habit.

Thanks.

[massenmedium]

Right, to continue this monologue.

Select the whole sample in clip view and right-click 'Delete Transients'.

Looks promising. I'll experiment with this and see if it reduces the tendency to generate those huge amounts of data.

....

A .alc clip file containing all the grey transient markers for that file = 94KB, without = 5KB

I'm not sure if that accounts for it but it might.*

The .asd analysis file for that .wav is 660KB. I wonder how many times that is being stored in memory? It should be only once I think...

*

OK - the offending track in my project had 1519 clips. They were small chops from one big file.

1519 * 94KB = 139.4MB

So I guess that's it. The moral of the story is - delete your transients like you used to delete the old warp markers. Except there isn't a convenient Select All.