Ableton Forum

i have noticed this since the betas for v6, but didnt really consider this to be a bug - more an issue...

my old powerbook 867 running live 5 use to render faster than a new macbook pro with a 2.16 processor and almost twice the RAM???

it's been quite frustrating lately: rendering a 3.30 track as individual tracks takes a considerable amount of time with live 6.

not only that but some of the renders had glitches... this seemed to happen if the audio started immediately at the beginning of the clip on the arrange. the rendered file (a bass sound) would have a huge spike to 0dB on the attack of the first note.
the rest of the file had attack peaks of around -6 dB...

the workaround seems to be to have a lead in of a bar or so in the actual clip, before the sound actually starts...

anyone else notice this?

I'm having a similar problem with Live 6.0.1 when rendering long dj mixes. at random points a clip will change tempo randomly and distort. sometimes, the audio stops completely on one audio track and the tempo starts behaving erratically. i've contacted ableton support about this as well.

justin wrote: not only that but some of the renders had glitches... this seemed to happen if the audio started immediately at the beginning of the clip on the arrange. the rendered file (a bass sound) would have a huge spike to 0dB on the attack of the first note.
the rest of the file had attack peaks of around -6 dB...

the workaround seems to be to have a lead in of a bar or so in the actual clip, before the sound actually starts...

anyone else notice this?

I've had a problem like this with grain delays that only shows up during rendering (well, also the very first time the device receives audio after you start live) -- if the delay has a high feedback you get an audio spike for half a second or so until the feedback settles down to normal. If this is your problem, one workaround is what you describe, but a slightly better workaround is automating the delay so its feedback is 0 when it first receives audio. (I had this problem on my nov. co:lab set where it happens immediately, so having a lead-in didn't work).

I've reported this to support; they were able to reproduce it and said the developers were taking a look, so hopefully it will be fixed soon.

no grain delay on the track for me, nor any other delay with hi feedback setting...
if i remember rightly, the only effect on the track was an autofilter set to lopass with a bit of resonance.

I, too, have noticed that rendering is very very slow on some of my live sets in Live 6.0.1.

First I thought this might be because for rendering only one core of multi-processor machines is used - so a set that makes great use of all 4 cores might 'render' (i.e. re-record in that case) faster in realtime than rendering offline.

But then I noticed that rendering is even slow for sets created in Live 5 (which, as we all know, has no multi-processor support). The same sets render much faster in Live 5 than in Live 6.