The Latency Thread?

[Orvillain]

If the latent track was latent by say 441 samples, it would have to be shifted in time to play 441 samples earlier.

But that isn't what happens. The non latent track is pushed ahead 441 samples, to sync up with the latent track.

Monitoring questions aside, this is how PDC works. A total figure is calculated, and then offsets are generated for each track and applied to keep them all in sync.

All of your DAW manuals that offer PDC will tell you this. Ableton is but one of them.

 

[Sascha Franck]

PDC is something different. PDC is about ensuring that tracks with latent plugins are kept in sync with tracks without latent plugins.

And it needs to be in sync with your live tracks every bit as much as with playback tracks. The only way to get there is latent tracks starting earlier.

 

[Orvillain]

And it needs to be in sync with your live tracks every bit as much as with playback tracks. The only way to get there is latent tracks starting earlier.

No.

The only way your live tracks can be in sync with your playback tracks is if they are kept out of the signal-flow of your playback tracks, and thus the DAW (if it is clever enough, which most are now) can use your multi-threaded modern computer, to process the monitoring tracks separately to the playback tracks, thus avoiding latency on them all together.

This is called low-latency monitoring in Studio One. Other DAW's call it something else.

But the moment those tracks feed into a buss at the same time as playback tracks with latent plugins on them, your monitored signal will also be latent. Because it will no longer be possible to process the monitor signal in it's own separate thread, due to the requirement of it going through the DSP of the plugins you've sent it to.

 

[Sascha Franck]

But the moment those tracks feed into a buss at the same time as playback tracks with latent plugins on them, your monitored signal will also be latent.

No. Only in case the bus has latent plugins on it. But that's an entirely different thing.

 

[Orvillain]

No. Only in case the bus has latent plugins on it. But that's an entirely different thing.

Yes, you're correct there. I wasn't specific enough. The latent plugin would have to be on the buss in order to affect the latency of any upstream monitoring channels.

But the point remains:

1. PDC and monitoring latency are two separate things. Don't confuse them.
2. PDC is about syncing up playback tracks with plugins on them - some plugins cause more latency than others, so these tracks need to be sync'd. Most DAW's to my knowledge will calculate offsets based on the most latent track, and apply those offsets to make all of the other playback tracks match it; just as the Ableton manual/FAQ says.
3. Monitored tracks are processed in a different thread and are not subject to any impacts of latent plugins, unless the monitor track(s) feed into a buss that has those latent plugins on it.

 

[Sascha Franck]

3. Monitored tracks are processed in a different thread and are not subject to any impacts of latent plugins, unless the monitor track(s) feed into a buss that has those latent plugins on it.

PDC along with live tracks already worked with single threaded CPUs.

 

[Orvillain]

Channels with a delay value of 0 get a 721 compensation value applied to them. Channels with a delay value of 88 get a 633 compensation applied to them. 633+88=721. Channels with a delay value of 32 get a 689 compensation applied to them. 689+32=721. The largest delay value in the mix is 721. That track has a 0 value for it's compensation.

It appears by the presence of the +/- that a negative compensation value is plausible. I've never seen it myself, but I'm willing to believe it is possible. However I struggle to think of a situation where you would have some tracks pushed ahead in time, and some tracks pulled closer in time. Answers on a postcard.

All the other info is here: https://macprovideo.com/article/audio-software/understanding-plug-in-delay-compensation

 

[Sascha Franck]

First off: For any normal playback situation, it is completely irrelevant whether we call the most latent tracks "played early" or the least latent tracks "delayed". It simply doesn't matter (and quite obviously, nobody is talking about "negative time" or whatever.
Fact is: When you press start, the most latent tracks get played first. No way around it.

As said, for plain playback, it doesn't matter how we call it.

Things get fundamentally different once live tracks are involved.

So:

3. Monitored tracks are processed in a different thread and are not subject to any impacts of latent plugins, unless the monitor track(s) feed into a buss that has those latent plugins on it.

They are not only processed, but sometimes you also want to record them.

Let's for now assume 0 would be the point on out time axis where our recording is supposed to start (and hence be placed at, once done).
Oh whoopsie, there's a plugin inserted on another track, introducing a latency of 12ms. Ok, let's place our recording at 0 +12ms. Oh noooo, before we track our next take, another plugin was inserted on another track, this time introducing 23ms of latency - hmpf, now our recording needs to be placed at 0 +23ms.
You can easily see where this is going, can you? Each time we record something, it needs to be checked whether there's another latency introducing plugin somewhere.
If however the latent track in question was started earlier (in relation to 0 - and btw, 0 is *never* representing the moment when we press start anyway, that's always happening earlier due to some pre-roll happening), that's the only calculation that had to be done. Quite easier in my book.

But hey, the story continues.
If what you were saying was true, you couldn't send a live track to, say, the same delay bus as a latent track that has to be compensated. Or rather, if that was happening, the delay would be out of time for one of the sources. Correct?
But that doesn't happen.
The reason being that the latent track is played early. Which is solving all issues instantly. If the delay bus would have to be delayed (which it would have to be, following your assumptions), how could the delay be in time with my live playing?

But hey, I'm sure you have yet another explanation of how that delay bus scenario would work.

 

[Sascha Franck]

Some more "btw"s...

The only way your live tracks can be in sync with your playback tracks is if they are kept out of the signal-flow of your playback tracks,

Negative. See my delay bus example. All the way mixed signal flow.

This is called low-latency monitoring in Studio One. Other DAW's call it something else.

Hasn't got anything to do with PDC, though.
Logic hss it as well, it's disabling all latency introducing plugins on the live-track's path (you can set the threshold yourself).

It appears by the presence of the +/- that a negative compensation value is plausible. I've never seen it myself, but I'm willing to believe it is possible.

It's part of the region parameters of sequencers since decades already. Why shouldn't it be used by PDC as well?

 

[Orvillain]

Honestly, I really can't be arsed with this anymore. Fine. Have it your way. DAW PDC technology causes tracks to play early, despite what the DAW manuals and FAQ's tell us.

OKAY.

I'll take my 18 years working in music tech, and skedaddle! I'm out.

 

[Sascha Franck]

Honestly, I really can't be arsed with this anymore. Fine. Have it your way. DAW PDC technology causes tracks to play early, despite what the DAW manuals and FAQ's tell us.

If you were carefully reading what I wrote, you'd see how that doesn't clash with what I'm saying.

That "0" I was talking about earlier is an almost arbitrary, virtual number. And there's some buffering happening before anyway. So, you could call delays anything you want in case we're sticking with playback tracks. When you look from the latent tracks, non latent tracks are delayed positively. And when you look from the non latent tracks, the latent tracks are delayed negatively. With 0 being an arbitrary point, both POVs are as valid. Obviously, positive delays are easier to grasp in laymen terminology. Doesn't mean it's exactly happening like that under the hood, though.
It's only getting different once live tracks are involved. And one thing is for sure: Your explanation *does not* cover them ("The only way your live tracks can be in sync with your playback tracks is if they are kept out of the signal-flow of your playback tracks," - that's simply wrong). Whether my explanation is 100% correct might be some thing tbd, but yours defenitely isn't,

I'll take my 18 years working in music tech, and skedaddle! I'm out.

Oh, just 18 years? I started earlier. Who wins?

 

[Jim Roseberry]

But that isn't what happens. The non latent track is pushed ahead 441 samples, to sync up with the latent track.

Monitoring questions aside, this is how PDC works. A total figure is calculated, and then offsets are generated for each track and applied to keep them all in sync.

All of your DAW manuals that offer PDC will tell you this. Ableton is but one of them.

FWIW, I'm well aware of what automatic PDC is. Been dealing with it for decades.
I was explaining what Sascha meant (how Logic implements PDC).

What you're describing is (also) how Cakewalk implements automatic PDC.