PDC according to Sadowick

[Gnuus]

PDC: Plug-in Delay Compensation

Plug-in Delay Compensation compensates for latency introduced by plug-ins, ensuring that audio routed through each plug-in, or chain of plug-ins, is synchronized with all other audio.

Without PDC, the groove and timing of a mix will be out of sync if plug-ins are used on any or all tracks.

Here's Sadowick with a demonstration:

http://youtu.be/c-kL9O74so8

[Angstrom]

That's a good demonstration, but I wish he had mentioned that it's specifically the automation which is uncompensated in Ableton. Some people might assume its somehow the audio stream which is uncompensated, when in fact that's usually fine, it's the automation which is not aligned with the compensated audio which may cause issues.

A real world example might be a mute switch on a kick drum, set to turn on at exactly the bar start. You might find that the automation is not in sync with the actual kick drum start. Or more often - beat synced effects, such as those popular in M4L devices, where a filter changes "on the beat" will not respect the overall latency offset as reported by the PDC.

However, two kick drums in two separate channels, where one has a bunch of effects on : these will remain in sync with each other. PDC does actually work there.

[Alchemystic]

That's a good demonstration, but I wish he had mentioned that it's specifically the automation which is uncompensated in Ableton. Some people might assume its somehow the audio stream which is uncompensated, when in fact that's usually fine, it's the automation which is not aligned with the compensated audio which may cause issues.

A real world example might be a mute switch on a kick drum, set to turn on at exactly the bar start. You might find that the automation is not in sync with the actual kick drum start. Or more often - beat synced effects, such as those popular in M4L devices, where a filter changes "on the beat" will not respect the overall latency offset as reported by the PDC.

However, two kick drums in two separate channels, where one has a bunch of effects on : these will remain in sync with each other. PDC does actually work there.

Wow digging up an old thread here but Angstrom thanks for this. I'm actually working through how to get all the PDC worked out in my live set right now...I like to use a lot of effects and automations and envelopes and sometimes Ableton doesn't quite want to do what I'm imagining in my head. I never knew that about the automation before but that definitely explains some of it. ...could you or anyone else perhaps point me toward some more good resources on this?

[Angstrom]

Yeah, This is old!
many things have been fixed since 2014.
the current situation as far as I know is : Since Live 9.2 Automation is now plugin delay compensated.Audio latency has been auto compensated.(since a long time back).
In L9.2 they added a bunch of stuff, including methods to show latency of chains of devices (see link below)

Things which are not yet, currently compensated (as of July 2016):

• Any audio stream in a feedback loop, or could potentially be in a feedback loop, such as return tracks with their own sends activated. These aren't compensated. This is not a bug, it's the nature of reality that a feedback loop is cumulative.
• beat synched devices, including VSTs, or MAX devices, are not compensated. That means things like beatrepeat/ slicer plugins which rely on host clock information may sound out of time
• graphics are not compensated. the image of the envelope or the note may appear to be out of synch with the sounds

In addition to that it's worth understanding what "Reduced Latency when Monitoring" is about because that can confuse users. It's a very useful feature - but you have to read what it's for, and how it affects latency when you have a track armed versus not armed.

It's all explained here.

https://www.ableton.com/en/help/article/latency-faqs/

[Alchemystic]

Thank you!! I was actually just reading that very link ^_^

I've been using Ableton since ~8 I believe (2009ish), but that was my first time ever working in a DAW and I really never used it to its full potential. In the past couple of years I've been steadily learning more and really started to piece it together. Getting a point where I need to digest some of the more advanced concepts to keep getting better. Some of the things affecting routings and internal workings I've never had to figure out in this or any DAW before so I'm learning as I go...I actually had just convinced myself last week I need to go through my sets and set all the track delay offsets to compensate for the delays in some of the fx chains I have in various places...and now I find out that it does it automatically! Lol...well, best way to learn is by doing...

So that raises another question in my mind - now that (almost) everything is auto-compensated, is there really any use for the track offset feature other than doing tricks like the Haas effect? Is there any way to compensate for those other cases? I was reading on that faq you linked that in the case of devices that rely on the host clock it also seems to depend on where in the fx chain they're located?

Grateful to be learning all this, thanks!

[Stromkraft]

[*]beat synched devices, including VSTs, or MAX devices, are not compensated. That means things like beatrepeat/ slicer plugins which rely on host clock information may sound out of time

Given that the user can compensate this by ear I still don't fully grasp the basis for this limitation. What info is missing? The tempo is known at each sample of time, the compensation needed is known. What else is needed?

[Angstrom]

I'm not an expert but this is my understanding :
the audio stream of a BeatRepeat type plugin is compensated just fine.
It's the discrepancy between the many corrected streams and the clock which is the issue.

the audio streams of many different latencies are all put in sync with the slowest stream calculation - imagine a race where everyone has to cross the line at the same time as the slowest runner. Here we have maintained synchrony of audio streams. The many runners, their footsteps (or beats) all match each other.
They are in relative sync with each other by offsetting to the slowest participant.

Clock sync is different.
Imagine that we need all those the mass of runners to all cross the line at a specific time!

my analogy breaks down under scrutiny, but the eessence is that the master clock is saying "go. go. go." on the beat. Then each plugin performs the action "on that beat", but then each plugin runs its DSP calculations at different speeds, and their eventual audio output is slow by different amounts. PDC puts the audio in time.

So you have an issue, which do you put in time? Is it the clocks you put in time? Because now you 'll hear the audio latencies. Or do you put the audio in time and hear the clock being "offset".

tl;dr
On absolute time, or in relative sync ? You may pick one.

EDIT

I obviously am bored at work



Note: this is all just my understanding, which is quite different from "facts".

[Stromkraft]

It's the discrepancy between the many corrected streams and the clock which is the issue.

the audio streams of many different latencies are all put in sync with the slowest stream calculation - imagine a race where everyone has to cross the line at the same time as the slowest runner. Here we have maintained synchrony of audio streams. The many runners, their footsteps (or beats) all match each other.
They are in relative sync with each other by offsetting to the slowest participant.

Clock sync is different.
Imagine that we need all those the mass of runners to all cross the line at a specific time!

My solution would simply be to delay compensate the clock, or rather the execution of the clock in the synced device or plug-in. For effects, the clock is mainly about tempo. Execution can happen on clock time, but obviously execution, or the resulting audio, can be delayed, or phase shifted, with the same amount as delay compensated audio. If I can do it manually, so can Live. There may be finer points of this that I don't understand fully, but I think this shoudl be possible to some extent.

How do other DAWs resolve this problem?

[Angstrom]

yes, for that to work you'd have to take the output latency of each audio stream and provide a different offset-clock input back to the chain based on that chain's latency
Obviously that would have to be on a per-chain basis, otherwise chains would be out of sync with each other.
So each chain in Live would need its own latency compensated clock input, rather than respecting the master.
You'd have to supply this to every chain, just in case - because AFAIK there's no standardised "this plugin needs a clock" flag for VSTs, they just take what's given, not announce what they are taking.

I can imagine there will be a few problems implementing an offset clock for every chain. That could be quite a drain on resources in a set with 20 tracks, each with (eg) a drum rack with a nested unevenly branching hierarchy of 20 chains in.

"This set needs 400 differently offset clocks please, oh and make sure the latency is recalculated regularly with no jitter! And I don't want to hear any pops or gaps in my playback!"

Yikes.
I can see why it's not in 9.6!

[Stromkraft]

You'd have to supply this to every chain, just in case - because AFAIK there's no standardised "this plugin needs a clock" flag for VSTs, they just take what's given, not announce what they are taking.

One step I suppose would be to make announcing happen for the native devices. Or to make it an optional manual setting that you control yourself with a suggestion. I use very few synced effects, so I don't know about 400. Also, once you have a PDC value for synced effect, that should be it, as most devices only need tempo syncing. You don't need to recalculate every sample to achieve that. I admit this problem space is probably riddled with hidden quagmires. Which is why I ask how other DAWs solve this problem. This is a shared problem among all DAWs? Thank god for the offset control, which I typically use.

[Angstrom]

Which is why I ask how other DAWs solve this problem. This is a shared problem among all DAWs? Thank god for the offset control, which I typically use.

Well, I'm just an internet-guesser with no real clues but ... Live is quite different from other DAWs in this respect.

What other DAWS do is purely on each channel. You might have a device chain on RME:Midi channel 1, and you can set the clock on RME: MIDI chan 1 to offset -25ms .
Protools allows Midi beat Clock offsets on a port by port basis LINK. And I think that's how Cubase does it too.

So - in Live we are working with a parallel nested chains in racks. A MIDI rack full of parallels, then an Instrument rack full of parallels, then an Effect Rack full of parallels.
In fact, the Instrument rack might have MIDI racks and effects racks nested in there too (mine certainly do!)

So where Protools could say "offset the beat clock for Port A, Channel 1" and it's a clock offset for a single series chain. In Live we have something which looks like a multidimensional branchy tree.

I am guessing like a motherfucker right here.