Sync Latency Compensation DISASTER

[baseinstinct]

End of discussion. Now, try & convince maky35 that he does not need that LOL.

Hopefully, this get sorted within Live by the end of v11.

[xanthos]

And here we are, Ableton Live 12 gets released today - and guess what, the PDC issues still alive!

I give up all my hopes that Ableton will fix this anytime soon.

[SpecialGuest]

Sync is not resolved at all in live 12. I'm testing this up and down and keep latency has nothing to do with tempo synced plugins running in sync. This is just a per track way to have people playing acoustic instruments record in time that don't have direct monitoring on their audio interface.

Someone much earlier described why Ableton resolved to do this - because they want a Max for live device that has multiple remote map destinations to play in sync with those remote mappings. The solution is obvious though: On any Max for live device that does remote mapping you simply have a toggle to compensate for pluggin delay or not per destination parameter and that would fix this whole issue. Ableton can then correctly adjust its transport position as published to the plugins, including its own plugins like auto pan.

And to those that read this whole thread although there are several different topics here - the max for live devices (like shaper) will never actually be sample accurate in their current state and there is also jitter. At best you could hope for +- one millisecond. A message cannot be guaranteed to arrive at any certain time. The control information is about a 44th as fast if you're at 44.1 sample rate and also it's in a lower priority queue. Audio rate modulation is an illusion. You are reliant on any destination parameter to have built in interpolation over at minimum one millisecond to reduce inharmonic zipper noise.

This also means that using midi triggers for envelopes suffer the same fate. Yes it will be much more accurate then a uniformly phase offset lfo due to running linear phase or some other plugin which introduces a lot of latency on any other track. This has nothing to do with if it's on the same track. Front loading host Synced plugins does not fix this. If a tempo synced plug in runs on a parallel track with no delay introducing plugins before it it will run in sync to the transport. This is one rare scenario. If it runs on a return bus it will already be delayed / out of sync. If it runs on a regular Ableton Track being used as a destination bus (instead of master etc) it will already be delayed/ oos. Your kick is masking this for virtual sidechain ducking and so it doesn't really matter most of the time for that. It does matter for stuff like shaper box or other really awesome host synced modulation effects like shade.

Also final note if you're just trying to duck something in response to usually a kick you have many many options for this aside from a tempo synced ducking tool. In fact if you please you can do a bunch of tests with regular side chaining or using something like Pro MB to duck specific bands and you will find that that good old method works most of the time anyway it's just not as nifty.

[jbone1313]

I'm testing this up and down and keep latency has nothing to do with tempo synced plugins running in sync.

Correct. I just deleted my reply above, as I had replied to the wrong thread.

Someone much earlier described why Ableton resolved to do this - because they want a Max for live device that has multiple remote map destinations to play in sync with those remote mappings. The solution is obvious though: On any Max for live device that does remote mapping you simply have a toggle to compensate for pluggin delay or not per destination parameter and that would fix this whole issue. Ableton can then correctly adjust its transport position as published to the plugins, including its own plugins like auto pan.

I am not exactly sure why Ableton does not delay compensate tempo synced plugins, but I don't see how it is related to Max for Live. IIRC, as this was an issue way before Max for Live existed. I have done a lot of coding and messing with tempo syncing in Max for Live. From what I can tell, the fundamental issue is the way the transport's time is calculated vs how tempo synced plugin timing is calculated combined with floating point precision. It seems like it is difficult or impossible to have 100% accuracy when syncing plugins to transports, and Ableton is not alone in that issue. I cannot remember all of the details. That said, you should check out this thread I created in March, which proposes a different solution. Please reply to that thread and let me know what you think.

My guess is Ableton does not attempt to delay compensate tempo synced plugins because they do not want to give users the illusion that it is 100% accurate, but as I explained in the thread I linked to, I don't think that has to be a problem, and the solution I proposed would be better than the status quo.

And to those that read this whole thread although there are several different topics here

Yep. It can be confusing.

[baseinstinct]

How is it solved in bitwig and other daws?

Last time I checked in cubase, which was ages ago, in sx1, the issue was the same.

[SpecialGuest]

You take the total plugin compensation value in samples and adjust the tempo information fed for transport playback to the plugins.

[jbone1313]

Converting beat-time values to samples under the hood seems like it would always be inaccurate at certain tempos due to floating point math and how certain numbers do not divide evenly. If I had to guess, then I would say that is why Ableton has not implemented this. As I wrote in this thread, I think they should give us the option and warn us that it is inaccurate. As long as the float precision is high enough, most people won't care. IIRC, with high enough precision, the amount of drift would be like nanoseconds over like 24 hours.

[baseinstinct]

Very interesting. If that is the case there should be 'preferred' tempos burdened with less error. And the one able to make out which values that would be?

[jbone1313]

No, that would only be the case IF Ableton implemented my suggestion. Currently, the tempos don't drift, but they are not latency compensated.

[baseinstinct]

Looks like the discussion has forked, so happy for you to follow through with your case, and here is mine:



It was discussed earlier, so just a recap. TTBOMK, track playback IS compensated, no matter how heavy plugins. What I have been advocating for is delay compensation of material RECORDED to wav.

So as per picture above, if you drag from looper to a new track and play it against the source one, lag will be appparent, and it is the new track with just audio will lag. This means that it is the RECORDING that is still not compensated, as it was first noticed back around Live 6 I think.

The same happens when you record this track's audio to another track



Interestingly, this seems to imply that here, the destination audio track picks up from the source where the looper would be - not at track's output, which IS compensated

That's all from me. I think the case is quite clear. The same happens in Traktor, which makes me think the issue might not be trivial to solve because it is too messy to be overlooked by A / NI teams.

Over to you guys.

[jbone1313]

I think the behavior in your case is due to the way Ableton's delay compensation system works. To perform delay compensation, all tracks are delayed to the longest track latency time. The problem for you is that compensation is happening to OTHER tracks - not your track. So, when you tap the output of your track, it is still delayed, because again, it is the OTHER tracks which are being delayed to catch up with yours. It's obviously counterintuitive, and I am not sure if it is physically possible to make a DAW do what you want it to do. MIDI is similar, and I too would love to be able to tap delay compensated MIDI.

[baseinstinct]

I would say that that silence at the beginning of the clip, and this gets compounded with each iteration, is evidence for the audio being written without compensating. If to play back delay compensation affects all tracks, I can see no reason for a new audio track with no plugins not to be considered by live.

Their missing compensation is quite apparent as this stage.

If upon the recording such a clip you have to zoom in and move the start marker to the first wave, that's room for automation.

Here is an attempt at the required modification to the algorithm.
Record the loop a bit longer , truncate the initial part that is silence even before the audio is written down to disk and shows as a clip. The delay value is already there calculated properly if the heavy source track does play in sync with all the rest of the project.

Now that Ableton relies on AVX2, there is no excuse