Ableton Forum

This should be really simple, it'll only take a couple of minutes. Hopefully we can get a picture of this issue and see if it's just a few people affected or lots. Or just me.

(Edited to add: check my post later about sample accurate timing at different BPMs. Also, try this test at 145BPM. Ignore the test using the VST.)

Find a nice kick loop - say, 4 bars long. I find that psy trance kicks are good for this as they have a sharp attack which really shows up phasing issues. But any minimal percussion should do.

Create two audio tracks. Call them 'Beat' and 'Bounce'.

Make sure delay compensation is ticked in the options menu.

Put the kick loop into the 'Beat' track and set the loop markers around it. Turn on looping.

Put a VST effect on the 'Beat' track. Any effect will do, but it has to be a VST, rather than an Ableton built-in.

Turn the effect off.

Now, set the output of 'Beat' to 'Bounce'.

Set Monitor to 'in' on 'Bounce'.

Arm 'Bounce'.

Click stop twice, then record, then play.

-----------------------------

My result was a severe delay. The delay increased based on the number of VST effects in the 'Beat' chain.

Try turning off delay compensation.

-----------------------------

Now use the same set-up, but set the 'Audio To' on the Beat track to 'sends only' and the 'Audio From' on 'Bounce' to 'Beat'. Start recording the loop again.

-----------------------------

My result was a seemingly synched record. Closer examination showed a small delay, which could be heard as high pitched phasing/corruption on the attack.

-----------------------------

Now set the loop recording and leave it running for several iterations. As you do this, zoom as far as you can go into an obvious attack in the 'Beat' track. Watch the waveform being recorded in the 'Bounce' track over several loops.

-----------------------------

My result was a slow creeping forward of the bounced audio on every loop. It seemed more pronounced for shorter loops.

-----------------------------

For bonus points, after stopping the recording, try fixing any timing issues you experienced by zooming in to the sample view for the recorded audio (bottom pane) and moving the whole loop brace to the right.

If you find that difficult, try zooming out until you can see the rightmost loop marker. Move it a big chunk right, zoom in a bit and move it left (with alt pressed, so you can move it without snapping).

-----------------------------

I found it impossible to move the loop brace to the right if I couldn't see the rightmost loop marker. Moving it left seemed to be unaffected.

Even when I moved the brace (and the start and stop points), I still had timing issues, which I found a touch confusing.

-----------------------------

I'm on Live 8.1.3 (Suite) and XP. I would really, really appreciate you taking a little time to investigate this with me.

Thanks!

Do you think it's related to or the same as this: http://forum.ableton.com/viewtopic.php?f=2&t=144386

The solution there was to turn the Audio From on the receiving track (the one monitoring incoming tracks) to None rather than the default Ext In.

As you can see I sent a bug report.

Came up here as well: http://forum.ableton.com/viewtopic.php?f=2&t=144503

Very interesting, thanks for digging them up. That problem definitely sounds like it relates to the second problem in my post.

The first problem is a little more severe though - each VST plug-in adds about a quarter of a beat of delay. This goes beyond phasing.

The third problem - the cumulative effect of the sample innacuracy - seems to be new to Live 8.

Without experimentation I can't tell if your solution helps - I'm at work at the mo - but I'll try this evening. I suspect I will be confounded again. The large delay can be fixed by changing the routing or turning off delay compensation, but the new routing seems incompatible with your fix and turning off compensation on a complex chain can be problematic.

Here's hoping it works though.

I'm discussing it with support as well, I'll share anything which results from that.

Well the thing about that issue is that although it seems to be 'caused' by having Audio From set to Ext In on the monitoring track, it only actually shows up if you have a plugin in the send. So definitely try setting your Audio From to None I would say.

You don't need to turn off delay compensation and the only thing it would affect is if you are actually monitoring or recording from an external source. It changes nothing as far as monitoring other tracks goes.

Does sound like there might some different issues there though. One thing I think might be happening is that trying to compensate for internal delay and latency from the soundcard input on the same track is somehow throwing things out.

massenmedium wrote:Well the thing about that issue is that although it seems to be 'caused' by having Audio From set to Ext In on the monitoring track, it only actually shows up if you have a plugin in the send. So definitely try setting your Audio From to None I would say.

You don't need to turn off delay compensation and the only thing it would affect is if you are actually monitoring or recording from an external source. It changes nothing as far as monitoring other tracks goes.

Does sound like there might some different issues there though. One thing I think might be happening is that trying to compensate for internal delay and latency from the soundcard input on the same track is somehow throwing things out.

I really hope you're right.

'You don't need to turn off delay compensation'

It does have an effect on the first problem though. It certainly feels like two individual issues.

Can't really look into it all in depth right now but I tried your first scenario and got some slight delays between the original and the recording. Setting Ext In on the 'bounce' track to No Input seems to fix it, or avoids the problem at any rate.

Using the latest beta (8.1.4b3).

I figure it's basically the same problem as in the other threads.

DJ Tequila wrote:'You don't need to turn off delay compensation'

It does have an effect on the first problem though. It certainly feels like two individual issues.

Yes it does seem to be related to the delay compensation under particular circumstances. Fortunately most people wont absolutely need to be recording from other tracks and monitoring external input on the same track very often. So it is something that can be gotten around.

OK, it's definitely two problems.

The great news is that the large delay is fixed using your tip. Nice one, thanks! Seems that, at least, was just an amplified version of the same issue.

The bad news is that I'm still getting a delay (only a few samples by the looks of it), along with a slow creeping forward with each iteration of the loop. This is when zoomed in to the max and looping four beats.

Do you not get this? Does anyone other than me?

Found out something else. If you zoom into the beginning of the loop section, the recorded audio looks in time on the first pass. If you zoom into the second beat (or anywhere later on in the loop) the first pass of recorded audio looks out of time.

It's like the record speed isn't the same as the play speed.

In both cases the second pass creeps along by a few samples.

It's happening with two sound cards - an internal one and an external USB device.

So... Anyone else?

OK, I found out from support what the issue was.

At most BPMs, you can't exactly fit a whole number of samples in a bar. (BPMs like 120, 144 and 175 are OK, for example).

I was running tests at 145 BPM, so I could see the small inaccuracies from the sample frames being shifted. Anyone testing from fresh would be using 120 so wouldn't see it.

It was compounded by the fact that these inaccuracies aren't corrected during looping, so they build up as the loops cycle. It's worth knowing this if you work at a BPM which isn't sample accurate and you like recording long loops from track to track... You could end up with a long recording going slowly out of time. It's amazing how quickly sonic artefacts build up from the process.

Good to hear you got an answer on that.

Can you counter the problem using follow actions to re-trigger the clip periodically?

In the meantime I've come across another couple of strange things to do with timing but I've not been able to isolate what's causing it just yet...

massenmedium wrote:Good to hear you got an answer on that.

Can you counter the problem using follow actions to re-trigger the clip periodically?

I wouldn't have thought so. It's a problem with physics!

Basically, the loop you're recording isn't a whole number of samples long. This means the recorded loop gains a partial sample at the end of each loop. Over time this adds up...

Triggering samples won't affect this. My demo track used four individual kick samples...

Seems like it can only be countered by using a sample-accurate BPM. Like 145, 120 or 175. Or calculating a fractional BPM near the one you desire.

massenmedium wrote:In the meantime I've come across another couple of strange things to do with timing but I've not been able to isolate what's causing it just yet...

I'd love to hear 'em...