Known Issues list: Here it is! ;)

[Timur]

Unfortunately the latest Beta Update 7.03 still does not seem to adress some of the worst bugs (to me) in Live. I don't like pointing at the same issues again and again and I do not do it to make Ableton look bad. But since some of these have been reported several months ago (even with audio- and video-documentation being provided) and no concrete answers (if any) have been given by Ableton about a solution it seems to be the only way to keep them from being forgotten and letting their customers know that these issues exists.

Anyone feel free to supplement the list so that people know which problems could be striking them and thus be prepared about them.


- Midi Clock dropout issues: Live as Master Midi Clock drops Midi Clock events when getting busy, so better use an external Midi Clock Master.

- Midi CPU-load issues: Live cannot even handle the 3125 bytes/s Midi bandwidth defined in the Midi standard without producing considerate CPU-load spikes, even on modern multi-überpower-don'tknowwhat CPUs.

- VST Plugin Buffer timings: Better don't use Plugin Buffers higher than 512, better stay below 256, else you wont be happy with the outcome (altering timing, resulting sound modulation). If you are using Audio Buffers higher than 512 then change the Plugin Buffer setting from the default "As Audio Buffers" to a fixed value.

- Vista GUI CPU-load issues in Basic mode: Do we all need 8800 GTs for running Live now? Will there be performance shootouts of nitrogen-cooled overclocking system using Live GUI as benchmark soon? Anyway, it works with 3D Aero but it does not work with the plain and simple 2D desktop.

- Midi-Yoke hanging/crashing issues: Is it Midi-Yoke or is it Live? Does it happen with physical Midi ports, too, just not as easily trackable?

- Memory managment/swapping issues: You can easily make Live use over 1 GB of RAM with nothing loaded but a single empty track. Also pagefile-swapping happening with lots of samples loaded but not used makes "SmartPriming" look weak/non-working. This can even lead to CPU-load with Live not doing ain't doing anything (including switched off audio-engine). Starting/loading a new set does not free up memory either, you need to restart Live in order to do that. External plugins should be fine, their memory is freed the very instance you unload them and they handle their own memory for samples themself.

- Missing DirectMusic support: Did you settle for MME only now or keep working on making DirectMusic useable?

- Copy/Paste issues: If using a quick combination of ctrl-c/ctrl-v it can easily happen that a track will not paste, but Live's memory usage still increases. Make sure to wait a second before pressing ctrl-v after copying a track. That's especially important if the copied track uses some external plugin like Battery that uses lots of memory on samples by itself. Since the copied track (including the plugin) does not show up in Live you have no chance to regain that memory without restarting at least the Set.

- GUI elements like Volume Meters and I/O controls leading to drop-outs even at low CPU-load: Better switch off volume-meters and I/O controls whenever you don't need them, especially if lots of Midi is happening in your set. This is not a CPU-load related issue, but switching those off can improve Live's performance considerably (less click/glitches). So if you ever wondered about drop-outs happening at even low CPU-load...

[dancerchris]

Yeah, I keep getting MIDI clicks and pops and none of the updates seem to want to address this. I suspect they overloaded something when they went to the 64 bit engine. Ableton support is suggesting it's my audio interface (presonus firepod) or a rogue VST. Probably not. More than likely it's something along what you're suggesting. I'm going to try all the things support recommended this weekend.

[dphouse84]

how about fixing the problem with the novation midi controllers? nay news on this?

[naph]

- VST Plugin Buffer timings: Better don't use Plugin Buffers higher than 512, better stay below 256, else you wont be happy with the outcome (altering timing, resulting sound modulation). If you are using Audio Buffers higher than 512 then change the Plugin Buffer setting from the default "As Audio Buffers" to a fixed value.


thank you for pointing this out!

i found this one to be responsible of inconsistent render. i had strange modulation effect on track rendering i noticed lately. Expecially on channels with flanger/chorus.
basically, every render is giving a slightly different result, no way of getting the same identical track on 2 different renders.
Setting this to 256 solver the problem. thank you!

[Timur]

My pleasure! Please report your problem/finding to Ableton, so that they know that other people beside me suffer from it.

Any Plugin Buffer setting below 256 will increase CPU load (higher settings will lower CPU load even more). Personally I prefer 128 because from 128 downwards modulation with NI Battery is not audible for me anymore (inverse cancellation tests still show 'em) and the hit on CPU load/performance is still relatively small (about on par with Live's internal effects). 64 will work too, with considerable higher CPU load, though. 32 does not work at all (with my Battery tests)! It will lead to big timing jumps every few seconds (inverse cancellation tests show burst of audio-breakthrough instead of just short clicks and pops). Settings above 512 to 1024 will result in very audible timing problems with some VSTs (or maybe all) with clearly audible glitches.

So 128 or 256 samples seem to be the best setting at the moment. Still it's not completely free of modulation/timing-shifts. For Latency reasons you want to have Plugin Buffers as small as possible (their latency sum up to the latency of Audio Buffers when playing through VSTs), for CPU load reasons you want them as big as possible. It's about the same as with Audio Buffers.

[timothyallan]

My pleasure! Please report your problem/finding to Ableton, so that they know that other people beside me suffer from it.

Any Plugin Buffer setting below 256 will increase CPU load (higher settings will lower CPU load even more). Personally I prefer 128 because from 128 downwards modulation with NI Battery is not audible for me anymore (inverse cancellation tests still show 'em) and the hit on CPU load/performance is still relatively small (about on par with Live's internal effects). 64 will work too, with considerable higher CPU load, though. 32 does not work at all (with my Battery tests)! It will lead to big timing jumps every few seconds (inverse cancellation tests show burst of audio-breakthrough instead of just short clicks and pops). Settings above 512 to 1024 will result in very audible timing problems with some VSTs (or maybe all) with clearly audible glitches.

So 128 or 256 samples seem to be the best setting at the moment. Still it's not completely free of modulation/timing-shifts. For Latency reasons you want to have Plugin Buffers as small as possible (their latency sum up to the latency of Audio Buffers when playing through VSTs), for CPU load reasons you want them as big as possible. It's about the same as with Audio Buffers.

Is this on both OS X and PC platforms? Also, I wonder if this happens with AU's on a Mac, or just VST's.

[Timur]

I cannot tell, because I don't own a Mac yet. So if anyone owning a Mac wants to try I can provide you with simple instructions how to test it.

This old post of mine links to several audio-files demonstrating the issue. Unfortunately many of them are lost already, because they were not accessed for more than 60 days from that server. But the remaining ones should suffice.

http://www.ableton.com/forum/viewtopic. ... 915#603915

But hey, I just noticed that you were part of that old thread already anyway.

The last answer from Amaury was from Dec 20th 2007, no news since then, and no acknowledgement if this is a general issue/bug.

We'll investigate all of this in details. Quite a lot has already been done by our engine team guys, and we like to believe they know how to conduct a test.
...
But again, I'd suggest you don't spend too much energy on this. As far as quality is concerned, we investigated a lot, I mean a lot of time and resources on that in the last development phase, and are confident that the expertise of the people involved is reliable. Nonetheless, we'll make sure we continue that work.

[Timur]

*bumpidibump*

[hoffman2k]

If you're going to bump it, then you have to update it.
There are more issues known then the ones you personally experience

[Timur]

Then hopefully more people update it themself. This is an official invitation! But only put issues on the list that you either reported to Ableton yourself and got no answer from them about this being no bug, or those issues which Ableton has confessed to be known. Also edit out any issues once they are solved by later updates please.

[hoffman2k]

Meh, if things worked like that there would be no Tips and Tricks sticky.

[Pitch Black]

Starting/loading a new set does not free up memory either, you need to restart Live in order to do that.

On Mac OSX, restarting Live does not free up memory, it would seem. I can load a Live Set, wait 60sec for "opening samples" to complete. Then I can quit Live, re-launch Live and load the same Set: and "opening samples" takes 5 seconds. Clearly the RAM is not being flushed.

If this is an OSX issue, which Abe has hinted at, saying "there is not much we can do, but we investigate" I would love to hear some statement on the fruits (or otherwise) of that investigation.

[Amaury]

Starting/loading a new set does not free up memory either, you need to restart Live in order to do that.

On Mac OSX, restarting Live does not free up memory, it would seem. I can load a Live Set, wait 60sec for "opening samples" to complete. Then I can quit Live, re-launch Live and load the same Set: and "opening samples" takes 5 seconds. Clearly the RAM is not being flushed.

If this is an OSX issue, which Abe has hinted at, saying "there is not much we can do, but we investigate" I would love to hear some statement on the fruits (or otherwise) of that investigation.

Hi,

Pitch Black and I had a private conversation about this, and here is what has been said. I've asked our engineers about memory management, and here is what I got from them:

The Operating system file cache keeps files in the memory. These would be removed from memory if needed. This has nothing to do with Live, but with the system, and, in short, it does not take any resources: any resources that are needed will instantly be available.

Regards,
Amaury

[ARDJ]

Timur i am in fact fully up & running now with my midi out. I posted in that last thread: http://www.ableton.com/forum/viewtopic.php?t=86173

that i am fully working with this update. all my MIDI port types are set to MME and my CPU & audio device are not showing any spikes like they once were.

[Timur]

I've asked our engineers about memory management, and here is what I got from them:

The Operating system file cache keeps files in the memory. These would be removed from memory if needed. This has nothing to do with Live, but with the system, and, in short, it does not take any resources: any resources that are needed will instantly be available.

Hey Amaury, thanks for evaluating this, but while your statements might be correct for Pitch Black's OS X issue (I cannot verify this before I buy my MBP in summer) they are not applying to the Windows related memory managment oddities of Live. Anyway, if OS X offers any tools similiar to Task-Manager and the likes it should be no problem to find out wether the memory is used by Live or by the system-cache and wether it is freed or not.