Ableton 9.5 and the state of PDC

[2020]

This is often noticeable with effects that require timing, such as delays or plugins like LFOTool.

I'm with you on this, except I would change often to only. As you say this happens because the timing isn't corrected. This is what I and BDeep have been trying to tell you (although I called it MIDI).

You asked about the state of DPC in Live 9.5, and this is where things are at AFAIK. I saw nothing about any fix for this in the release notes for 9.5.

It seems to me you'd like to continue using Live. The workaround while waiting for Ableton to fix this, if they ever do, is to try and put your latency inducing plugin(s) after your timing/midi dependent ones in the chain. I understand that this isn't ideal, but it's miles better than it used to be.

[TheKid]

PDC works just fine. Midi timing does not. Check the Cableguys FAQ for PDC. There even is a workaround for the problem. Not great but working. http://www.cableguys.com/faq.html

[billcarroll]

PDC works just fine. Midi timing does not. Check the Cableguys FAQ for PDC. There even is a workaround for the problem. Not great but working. http://www.cableguys.com/faq.html

You have it backwards.

The solution in the Cableguys FAQ for PDC is to use MIDI to trigger voumeshaper instead of trying to reply on the non-functional PDC in Ableton Live.

[billcarroll]

This is often noticeable with effects that require timing, such as delays or plugins like LFOTool.

I'm with you on this, except I would change often to only. As you say this happens because the timing isn't corrected. This is what I and BDeep have been trying to tell you (although I called it MIDI).

You asked about the state of DPC in Live 9.5, and this is where things are at AFAIK. I saw nothing about any fix for this in the release notes for 9.5.

It seems to me you'd like to continue using Live. The workaround while waiting for Ableton to fix this, if they ever do, is to try and put your latency inducing plugin(s) after your timing/midi dependent ones in the chain. I understand that this isn't ideal, but it's miles better than it used to be.

I would have loved to continue using Ableton Live. I've used Live since 2004. When they get PDC sorted I might look at using it as my main DAW again. Until then, Ableton Live is essentially just a fantastic sampler rewired to Cubase 8. 3rd party plugins go in Cubase and there is no problem.

[TheKid]

Don't wanna post Einstein's quote about the infinity of the universe and mankind's stupidity... I'm out too.

[2020]

Wow, prefering Rewire to the workarounds mentioned here. Good on you man.

[billcarroll]

Don't wanna post Einstein's quote about the infinity of the universe and mankind's stupidity... I'm out too.

Directly from the Cableguys FAQ:

Q: FilterShaper, VolumeShaper, PanCake or MidiShaper work fine in Ableton Live when being the only plugin on a track. But they can show latency in other cases — this can (but does not have to) happen when there are several plugins on the track, or when used on a group or on an audio track with other tracks routed to it.

A: This is a PDC (Plugin Delay Compensation) issue of Ableton Live. Our plugins are synced to the timing information that is provided by Ableton Live. Sadly, Live does not take PDC into account here and thus the timing information provided by Live can be wrong. We've already talked about this with Ableton in 2011 and are glad about anyone who bugs them about this issue.

As a workaround, you can use FilterShaper's, VolumeShaper's or PanCake's oscilloscope to move the waveform to the left until timing matches again (use the arrow buttons below the waveform; SHIFT-click for precise adjustments).

[chroma]

This is often noticeable with effects that require timing, such as delays or plugins like LFOTool. This issue with Ableton Live PDC is why the offset control exists in LFOTool.

actually, delays or anything that just syncs to the midi clock to detect rates are usually fine. the problem is that the midi clock is delivered to all plugins on the track at the same time (in fact, all plugins in the project AFAIK), but the actual audio associated with that midi timeline location may not arrive until later.

For example, you have a bassline playing, and you put a 3rd party plugin on the bassline that introduces latency. After that 3rd party plugin you place an LFOTool to duck the bass for the kick. The bass notes will be played in time at the master channel, however the spot where the bass is ducked will not match where the kick hits. The bass ducking will be off by the number of samples introduced by the 3rd party plugin.

This is where you have the problem... most plugins don't really care about the midi timeline, they are either just processing audio, or care about the current BPM but not the exact location, or just respond to whatever midi event they are told immediately. but in this case, you have whatever is generating the bass, and LFO tool, both doing something at exactly (say) 2.3.0 (one playing a note, and the other controlling volume), and where they think the location 2.3.0 is, is not exactly the same.

However, this is less likely to occur than before... pre-9.2, _any_ plugin between the bassline and LFO Tool would introduce latency, and if you had multiple VSTs between, you'd get multiple latencies, _even if_ they were considered zero-latency plugins. Starting with 9.2, zero latency plugins are really zero latency plugins, so a lot of previously-nonworking cases will work fine now, just because there's no latency between the bass and the LFOTool anymore.

[billcarroll]

This is often noticeable with effects that require timing, such as delays or plugins like LFOTool. This issue with Ableton Live PDC is why the offset control exists in LFOTool.

actually, delays or anything that just syncs to the midi clock to detect rates are usually fine. the problem is that the midi clock is delivered to all plugins on the track at the same time (in fact, all plugins in the project AFAIK), but the actual audio associated with that midi timeline location may not arrive until later.

For example, you have a bassline playing, and you put a 3rd party plugin on the bassline that introduces latency. After that 3rd party plugin you place an LFOTool to duck the bass for the kick. The bass notes will be played in time at the master channel, however the spot where the bass is ducked will not match where the kick hits. The bass ducking will be off by the number of samples introduced by the 3rd party plugin.

This is where you have the problem... most plugins don't really care about the midi timeline, they are either just processing audio, or care about the current BPM but not the exact location, or just respond to whatever midi event they are told immediately. but in this case, you have whatever is generating the bass, and LFO tool, both doing something at exactly (say) 2.3.0 (one playing a note, and the other controlling volume), and where they think the location 2.3.0 is, is not exactly the same.

However, this is less likely to occur than before... pre-9.2, _any_ plugin between the bassline and LFO Tool would introduce latency, and if you had multiple VSTs between, you'd get multiple latencies, _even if_ they were considered zero-latency plugins. Starting with 9.2, zero latency plugins are really zero latency plugins, so a lot of previously-nonworking cases will work fine now, just because there's no latency between the bass and the LFOTool anymore.

I'm not sure what you mean by "midi timeline".

You are correct that Live no longer adds additional latency for each 3rd party plugin equal to 1 buffer setting in preferences. So, if a plugin has no latency, Live does not add latency like it used to. This reduces the PDC problem by 1 buffer setting. However, the PDC issue remains for any latency added by 3rd party plugins, and that latency is not compensated.

[sampsy]

Sorry to bump up an old thread, but just ran into this issue recently - again.

I recently snagged Stutter Edit from a sale, and had some fun with it. Then I strapped it on a master bus of this song I had been working on, and it behaved oddly. Being a glitch type of an effect I didn't immediately understand what was going on, but after trying to "debug" it, I found out what others have found out too: Ableton does PDC correctly for the audio streams (mixing, sends etc) but it does NOT report delay compensated host timing for the plugins. I made a short demonstration video:

As already stated, Cableguys Volumshaper suffers from the same issue, but for that plugin the issue can be worked around. However, there is no workaround for Stutter Edit. If you have any delay inducing plugins in your Live set, Stutter Edit is guaranteed to be out of sync, and will sound really different depending on the amount of latency. To me, this is quite unacceptable. It really makes Stutter Edit (and probably plenty of other live/lfo/glitch/etc plugins) unusable on live.

Ableton keeps saying that if this was just a bug, it would have been fixed promptly. I get that. But this issue has been known for AT LEAST 5 YEARS, already in Live 8. That's plenty of time to fix the problem.

Do you guys know how other DAWs handle this? Is it working on Bitwig? I tried their demo, but it had some serious usability issues. Might consider revisiting it again...

[tooneba]

When I checked before Studio One compensated host timing for each plugins.

[sampsy]

Just briefly tested out Bitwig demo 1.3.13 and there seems to be some problems as well. Will dig into it later this evening.

I guess this is rocket science

[sampsy]

I take it back. Bitwig seems to handle PDC perfectly.

Too bad there are some crucial usability issues that prevent me for switching over. Soloing MIDI channel that controls VST on another channel mutes the VST... sorry but no can do

[tedannemann]

All information needed is given here: https://www.ableton.com/de/help/article/latency-faqs/
(BTW most of this wasn't true before Live 9(!) )

The important part is (still true for Live 9.7):

Does Live compensate everything?

As of Live 9.2, audio, automation, and modulation are fully compensated. Graphics Elements are not compensated, thus the level meters and other graphic elements might be displayed slightly ahead of time with respect to the audio.

In addition to this, built-in device modulation which is synced to the Live transport (i.e., synced to a specific beat-time position) is not compensated. One example would be the Auto Filter LFO (in Sync mode), which might be slightly off depending on the position the device has in the effect chain. Specifically, if the Auto Filter is located after a number of devices introducing a large latency, the modulation might be offset to an earlier position with respect to the grid.

Note that this does not happen to all Ableton Devices relying on Live's tempo information, but rather only to those which sync to a specific song position. For example, Ping Pong Delay, Filter Delay, and Simple Delay do not present the problem and are always correctly compansated.

Plugins which are synced to a beat-time position are still not compensated. This includes all the usual pumping suspects like Wave's Pumper, Vengeance's Multiband-Sidechain, LFO-Tool, Kickstart and a whole bunch of other rhythm driven plugins.

This means if you are using beat synced plugins you can't put latency heavy plugins "before" them - otherwise you have to compensate for the introduced latency yourself (some of these plugins provide offset functions) or get the well known latency issues with Live (aka the wishy-washy sound due to the untight timing).

So watch out for beat synced plugins (including Lives own MIDI synced LFOs in their stock plugins!) as well as the routings for your return tracks.

[FXBox]

I wish they would sort this as I would be back with Ableton but from what I remember on the Ableton forums they can never sort it has it's part of the realtime engine