Ableton Looper sync playback latency problem?

[ethnotronik]

I have just came across this issue as I started using looper in ableton live 10 (most recent) MBP 2012 16gb RAM OSX
The input is direct, coming from UA apollo (realtime)

I have a fairly big live set, over 150 tracks, effects on the master channel, subgroups, group tracks, vst synths, audio clips...

As I start looping, when the looper plays back recorded audio following the grid, I hear lot of latency immediately. My project buffer is at 512, and I think it has to be there at all times for this live set.
I have tried compensating on the looper audio track arround -40, but it seems to me that this value is variable every time CPU is doing something different?! I have tried to search arround, it seems that people have similar issue without any concrete solution.
I need to figure this out fast. Either, I will try to make the Ableton looper work, or I will have a hardware looper as a separate device. I rather not to the second option, portability is the issue.

Does anyone have a practical solution, or this has been an ongoing problem in live?
Is there a workarround?
Is there a definite way to know the proper compensation values, or I have to guess by ear? Is this valuse of delay compensation variable, or is it fixed to global output latency of Live?

[yur2die4]

Compensation probably makes it worse. Many vsts can add to the problem too.

I’d test out the Looper on an empty set and see how different the experience is. If you’re having the same issues, you have no internal solutions.

If it is a dramatic improvement, and useable, then you have to decide whether to compromise in your set and change things in order to make performance more suitable or whether to resort to something external since you can’t meet your requirements using both a Looper and your set simultaneously.

[ethnotronik]

Thanks for the reply,

I have just tried to clean up the set, reduced the VST load to about half...
Put the buffer at 128, the CPU load is now around 25%
I think the looper is still slightly late, but much better than before...
Now, I am adjusting the delay...put it back around -30 and it seems in perfect sync...
But, still I am not really sure how this works...do not have a logical idea how the compensation numbers relate to each other
Will see if I can purge more things from the live set file...

[ethnotronik]

So, I did some further testing, bounced most of the VST's to audio, reduced the latency to 128, even 64 which gave me 45% CPU load. I eliminated the plugins that had latency 1+ ms and so on... some of the plugins showed zero latency...
I have 3 send effects and 4 busses for the stems (drums bass lead pad)
All of that made the looper out of the beat, out of sync.
Is there anything else I should try?

[yur2die4]

I use compensation for recording a session.
For live performance it depends on some factors. But adding delay per channel in this situation is probably not ideal.

Are you experiencing timing issues or drift? Is the quantization on in the Looper?

[[jur]]

Have you tried to enable "Reduce latency while monitoring" in the Options menu?

[ethnotronik]

I use compensation for recording a session.
For live performance it depends on some factors. But adding delay per channel in this situation is probably not ideal.

Are you experiencing timing issues or drift? Is the quantization on in the Looper?

I think the looper drifts from its timeline...this is noticeable when you play the 8th notes

[ethnotronik]

Have you tried to enable "Reduce latency while monitoring" in the Options menu?

I will try this right now...

[ethnotronik]

Have you tried to enable "Reduce latency while monitoring" in the Options menu?

I will try this right now...

I have tried this, it did not make a difference.
I am trying out different routing, turning off plugins, bouncing track to audio...
It seems that it works best with 64 buffer, but that is impossible to run the live set with considering the size of the project

Will getting a new macbook pro solve this problem, or this is something that has to do with a lack of latency compensation in looper module?

[yur2die4]

Part of the difficulty in diagnosing the issues is also determining more in depth how you’re actually using the Looper. If you do a single take and loop it, it should be pretty accurate. If you do 3 or 4 layers, they’ll incrementally add latency, this is especially tricky since you’re hearing or playing along to a guitar that will inevitably drift. If you always play to the beat and try not to ‘compensate’ by ear in your performance, you should be alright. The problem can get messy if you play along to yourself since there is no way to eliminate a delay in processing.

An external Looper might be better for this but would be a lot less convenient in many ways. But it’d probably have some slick features.

[[jur]]

If there really is a latency problem, then you should first determine which plugins are causing this, then see how it feels without them.
Also, this might sound stupid but just to be sure: isn't it about your global quantisation setting?

And don't forget that it's not easy as it seems to use a looper, it usually reveals how bad our timing is and needs some practice.

[Angstrom]

There are some existing issues with the Looper but this doesn't sound like one I know of.

In this case there's talk of a persistent and immediate latency on the looper of 40 ish ms also of the set having 150 tracks with a lot of VSTs and complex nested routings. That last part certainly sounds like the cause to me.

WHY:
If live is in "Reduced Latency when monitoring" mode then the other sibling tracks do not alter the latency of the channel with the looper on.
If RLWM mode is active the armed track's latency will be calculated in isolation regardless of timing relative to other sibling tracks. So sync is sacrificed to speed.
BUT if several tracks are armed with this mode active they will be out of time with each other. That's what RLWM mode does. it allows each path to be the fastest it can be regardless of relative sync. It's a fast-pass.

WHY COMPLEX ROUTING WILL MAKE THIS EVEN WORSE
if you send the looper into another channel, or set up complex send and return relationships then this is now all considered one stream. So, looper routed out into group, into buss, into send which also returns into the buss? Perhaps a compressor with a lookahead in there, or a CPU intensive mastering plugin, or Guitar rig, etc.
That kind of routing is un-calculable latency hell. Its all considered one stream and it will be out of sync. Add multiple armed tracks to that nested grouping of streams and RLWM mode and .... it's never going to work.

You cant have the "fast path to output" active (RLWM) and also maintain sync with other tracks. You can maintain sync if you turn RLWM off but you will then have all the latency of the other tracks and if they have a lot of processing on then there will be a lot of latency.

It's like that Venn Diagram: fast / cheap / good. Pick two. Personally I would not run 150 tracks of computational processing and complex routings for the reasons stated here. I flatten what will be unnoticeable to sample sets (bass, drums) and only compute what is essential for performing.

[ethnotronik]

so, I have reduced the set to half of the size, about 75-80 tracks, deleted all the sub groups, bounced most of the VST to audio, deleted inserts on the master channel, and on the subgroups (4 of them) deleted all the plugins that introduced latency, mostly sound toys and waves.

the only thing I have now is that each of the 11 songs are on a group track...will this create latency?
I am still having problem with the looper with syncing the audio with the rest of the project.
it is different than arming the track, recording the loop, and everything is in sync this way...

Need to find this culprit, will report the findings