Plugin Delay Compensation and Automation Delay Compensation

[jfrichards]

Every once in a while I see discussions about PDC and ADC, both about Reason and other DAW's. Can someone give me a concrete audio example of plugin delay or automation delay, and a comparison with when it has been fixed with PDC or ADC? When do people need it? How much does it happen? Does it happen when just using stock Reason devices? How about with Rack Extensions? If it is a serious problem, how to people deal with it in Reason? Is bouncing to audio always a solution? Any info would be appreciated. Any audio examples would be greatly appreciated.

[Vince-Noir-99]

Before someone provides any examples, I can say that basically it sounds like phasing, therefore thinning out or unbalancing the tone of the sound in question. It is a problem that happens with parallel processing, where different plugins with different latencies are on each track. Once the two (or more) parallel signals are summed back together, that tiny delay (typically less than a ms) will create the phasing effect, which in the case of any non time-based parallel processing like reverb, delay etc, is really not desirable.

A few years back protools engineers calculated the delay and nudged the audio accordingly. At least the few I've known.. Apparently now most DAWs do that automatically.

I know nothing about Automation Delay...

[avasopht]

Plugin Delay Compensation = compensating for plugin delays by delaying other tracks during playback and adjusting on export. For example your hi-hat might be delayed by 50ms, so you would delay every other track by 50ms to keep them in line with each other and when bouncing you'd cut out the first 50ms to compensate.

Auto Delay Compensation is when the plugin delay compensation is calculated by the DAW and handled automatically.

It is needed in plugins that requires lookahead. It might be a convolution reverb, linear phase EQ, lookahead compressor or a pitch effect like Polar or Neptune.

Only a few stock devices have plugin delay. MClass Maximizer when in lookahead mode has 4ms of plugin delay. Neptune and Polar also incur a delay and I suspect the FFT mode of the vocoder might too.

I've no idea about Rack Extensions in general but there is a thread about it. For reference the Waves' Ultra Maximizer introduced something like 90ms.

As to whether it's a serious problem; absolutely when you've got a 90ms delay and it's clearly noticeable, or if it introduces phasing issues in recording with multiple mics. You could bounce the audio and snip off the beginning yourself. This was a big problem in one track I made as I had created a custom compressor / limiter with a 90ms lookahead but also wanted to use Buffre for some fun effects which sounded odd because the loop was not in line with where the drums were landing.

[Olivier]

All about how you can deal with RE's that introduce delay using the VMG-01 by Normen Hansen:

[Vince-Noir-99]

Wow had no idea it could be as bad as 90ms

[avasopht]

All about how you can deal with RE's that introduce delay using the VMG-01 by Normen Hansen:

Doesn't solve plugin delay when attempting to sync buffre loops.

[zakalwe]

it just sounds a bit mushy at 3 samples but you can really hear the phasing at 1ms, like with softube FET with lookahead on max.

i think i tried some tests on stock devices a while ago but it can depend on the settings you use, maybe a phase change confusing the meter. all i remember is that scream 4 is completely weird and i kind of understand why i don't touch it with a barge pole.

[Olivier]

All about how you can deal with RE's that introduce delay using the VMG-01 by Normen Hansen:

Doesn't solve plugin delay when attempting to sync buffre loops.

Possibly.. i dunno what you're attempting to do

[avasopht]

Possibly.. i dunno what you're attempting to do

Just think about it, ...

Drums are delayed by say, 20ms. You use VMG-01 to delay other tracks, and now everything is delayed. You've programmed some Buffre repeats which are set to land on the bar, so now Buffre records from the bar, and therefore picks up the last 20ms of the previous bar and is looping the wrong section of audio.

With ADC I could just hit record, fire away at Buffre and my MIDI could happily be lined up with the bar and the audio too, instead I had to go in by hand and play around on the timeline to adjust the effect. It was more of an, "ohhh yeah, there was a plugin delay," moment than anything. It might have even been more down to me programming in my Buffre loops before inserting my effect or something, but in any case it did have a noticeable slightly disruptive effect.

[Olivier]

Possibly.. i dunno what you're attempting to do

Just think about it, ...

Drums are delayed by say, 20ms. You use VMG-01 to delay other tracks, and now everything is delayed. You've programmed some Buffre repeats which are set to land on the bar, so now Buffre records from the bar, and therefore picks up the last 20ms of the previous bar and is looping the wrong section of audio.

With ADC I could just hit record, fire away at Buffre and my MIDI could happily be lined up with the bar and the audio too, instead I had to go in by hand and play around on the timeline to adjust the effect. It was more of an, "ohhh yeah, there was a plugin delay," moment than anything. It might have even been more down to me programming in my Buffre loops before inserting my effect or something, but in any case it did have a noticeable slightly disruptive effect.

hmm... yeap.. then you'd need something more advanced (like ADC) indeed
i might've tried to bounce that track, pull it back 20ms and add buffre. But i can see how thats a hassle. Having ADC would defenitely be a plus.

[gak]

The thing that bothers me is that in the beginning, I swear to the daw gods I never noticed this. Why all of the sudden it's starting to be a "thing" perplexes me. It's as if I'm in the "matrix" and code is being altered in a non-conceivable way

EDIT: If live can do it after all this time, the props are EASILY capable of this

[avasopht]

The thing that bothers me is that in the beginning, I swear to the daw gods I never noticed this. Why all of the sudden it's starting to be a "thing" perplexes me. It's as if I'm in the "matrix" and code is being altered in a non-conceivable way

EDIT: If live can do it after all this time, the props are EASILY capable of this

Because of new DSP algorithms using methods like lookahead or convolution. Lookahead allows you to anticipate peaks and transients that otherwise wouldn't be caught.

Can't really comment on why it's not included, but there are considerations to make with ADC when getting it right, and I think Reason has a little bit of a pickle. Currently CV changes every 64 frames in line with the audio processing batches. ADC would bring them out of line, so if the old devices aren't designed to handle arbitrary CV positions then they might need to update the code for every single device before introducing ADC.

Plus you have to consider how Reason will have to process CV's. Will it just delay it to the next batch, will shift the CV (resulting in slightly different input results), would doing so greatly affect the sound of songs that sort of relied on specific CV values?

Long story short, there is much to figure out in this case.

[Theo.M]

The thing that bothers me is that in the beginning, I swear to the daw gods I never noticed this. Why all of the sudden it's starting to be a "thing" perplexes me. It's as if I'm in the "matrix" and code is being altered in a non-conceivable way

EDIT: If live can do it after all this time, the props are EASILY capable of this

because now there are a ton of RE's that have latency. And neptune was not a big deal cause you could just drag a vocal in time by ear (which you would have to do after a vocal recording anyway).

One can use reason stock and more or less not worry about it in 99% of situations. Oh, i think the softube amps have latency as well.