Live 6: inactive tracks taxing CPU

UHE is now closed. For Technical Support from Ableton, please go here: http://www.ableton.com/support
Locked
ilia
Posts: 787
Joined: Fri Apr 16, 2004 4:12 am
Location: New York
Contact:

Live 6: inactive tracks taxing CPU

Post by ilia » Thu Oct 05, 2006 8:18 pm

I don't know if this was the issue in Live 5, but I am definitely seeing it in 6.0.1.

I am trying to combine my various songs into one large performance set. Each song has its own separate set of tracks, usually 5-6, some are arangement tracks, others are live input processing tracks. When a particular song is active, all tracks from other songs are automated to have all their plugins and speaker off. Despite that, I see that many of these inactive tracks take 2-3% of the CPU (Pentium M 1.4). My set right now has about 45 audio tracks and 10 return tracks. I want to add more songs, but this issue is essentially grinding my CPU to a halt on sets that by themselves take only 50% of the CPU. I don't want to put all my songs on the same tracks, for reasons of clarity. Is there a way to completely disable a track?

I noticed that this has to do with routing. For example, if I disable track's input, it no longer takes CPU. Too bad this feature is not automateable.

I'd appreciate if Abes could respond to this; I am playing some festival shows very soon and really wanted to use 6 for them...

Andreas Zapf
Posts: 290
Joined: Mon Sep 08, 2003 10:01 am
Location: Ableton Headquarter
Contact:

Post by Andreas Zapf » Fri Oct 06, 2006 2:45 pm

Hi,

some of Live's devices will consume a little cpu load even when bypassed, probably that's what you notice. Currently there is no way to completely disable a track so that it uses no cpu. It was always like that in all versions of Live.

Regards,
Andreas

ilia
Posts: 787
Joined: Fri Apr 16, 2004 4:12 am
Location: New York
Contact:

Post by ilia » Fri Oct 06, 2006 5:00 pm

Andreas Zapf wrote:Hi,

some of Live's devices will consume a little cpu load even when bypassed, probably that's what you notice. Currently there is no way to completely disable a track so that it uses no cpu. It was always like that in all versions of Live.

Regards,
Andreas
Andreas -- I notice that this happens in tracks that are processing other tracks or external inputs. Out of live plugins, I only use EQ and utility, and I don't think they account for this drain.

Is this something connected to routing? Maybe there is some kind of work-around? Does the number of return tracks affect this?

Is this CPU drain caused by inactive VST plugins as well?

Will racking devices help any?

Thanks.

Andreas Zapf
Posts: 290
Joined: Mon Sep 08, 2003 10:01 am
Location: Ableton Headquarter
Contact:

Post by Andreas Zapf » Thu Oct 12, 2006 11:46 am

After some investigation I found that muting a speaker buttons may not always disable audio calculation in the following tracks. Could you try to add a utility device at the end of each track and automate its Mute button instead of the track's speaker button? It should be especially useful for external input tracks.

Thanks for directing me to that speaker button issue. It will be fixed in the future, but it's technically complicated, so I can't yet tell when.

Best,
Andreas

ilia
Posts: 787
Joined: Fri Apr 16, 2004 4:12 am
Location: New York
Contact:

Post by ilia » Fri Oct 13, 2006 7:30 am

Andreas Zapf wrote:After some investigation I found that muting a speaker buttons may not always disable audio calculation in the following tracks. Could you try to add a utility device at the end of each track and automate its Mute button instead of the track's speaker button? It should be especially useful for external input tracks.

Thanks for directing me to that speaker button issue. It will be fixed in the future, but it's technically complicated, so I can't yet tell when.
Andreas, thank you for following up on this. Unfortunately, the utility trick does not appear to help on my end. Perhaps you were talking about the situation when one could disable a track to stop the following tracks from processing it. In my case, I have for example 1 track that is routed into ten other tracks, and I need to disable 9 out of those 10.

After looking into this more, I can say that this issue is present in both Live 5 and 6, but it's much more serious in 6.

I loaded a set into Live 5 and played it from the spot where it takes 40% of my CPU. Then, by switching all inactive (speaker off, all plugins off) tracks' inputs to AUTO from IN I was able to reduce the CPU load to about 30%

The same set in Live 6 at the same spot took about 58-60% of the CPU. Again, switching all inactive tracks from IN to AUTO I could go down to 30%.

Putting muted 'utilities' on those tracks did not result in any change of the load.

I wish there were an automatable button to deactive a track, or perhaps the input state could be automated? As it is now, it looks like I cannot use Live 6 on some of my larger sets unless I get a faster computer.

ilia
Posts: 787
Joined: Fri Apr 16, 2004 4:12 am
Location: New York
Contact:

Post by ilia » Wed Nov 01, 2006 5:48 am

Any word on this? Still a major hurdle to using large sets with complex routing in Live 6. Perhaps you could at least add automation for track's IN/AUTO/OFF routing selection in an upcoming update?

Andreas Zapf
Posts: 290
Joined: Mon Sep 08, 2003 10:01 am
Location: Ableton Headquarter
Contact:

Post by Andreas Zapf » Wed Nov 08, 2006 12:09 pm

Sorry, I was out of office for some days.
I loaded a set into Live 5 and played it from the spot where it takes 40% of my CPU. Then, by switching all inactive (speaker off, all plugins off) tracks' inputs to AUTO from IN I was able to reduce the CPU load to about 30%

The same set in Live 6 at the same spot took about 58-60% of the CPU. Again, switching all inactive tracks from IN to AUTO I could go down to 30%.
We found an issue that could have caused this. It should be fixed in the next bugfix update, so that it should work as in Live 5.
I wish there were an automatable button to deactive a track, or perhaps the input state could be automated?
Switching the input state may involve recalculation of delay compensation which is very difficult to automate for several reasons. I don't think we can do this in a bugfix update, we'll consider it for a future main release.

Regards,
Andreas

Locked