What is Delay Compensation?

[FlowerSoldier]

Forgive the noob question. What is this Delay Compensation feature they're adding?

[platzangst]

Many complex operations, like generating effects, add computer processing time into an audio signal. There's a delay, often minimal, but sometimes noticeable. Delay compensation adjusts for that and works to sync up any delayed signals with the other tracks.

[avasopht]

Some plugins, such as the MClass Maximizer (with 4ms lookahead) introduce plugin delay so that the device can do some extra cool things that need it to be able to look ahead of the signal. So say like your kick began at sample 0, in a device with plugin delay it might now begin at sample 100.

This not only can throw channels out of time, but if you are doing parallel processing you will find the signals can interact and have a disasterous effect.

Automatic plugin delay compensation keeps all audio and midi / cv in alignment.

[Loque]

I am so excited by this feature. Finally parallel channels work well, also with amplifiets. No more phasing sounds! No more bouncing and adjusting. It was overtime to add this feature.

[FlowerSoldier]

Thanks for the info - that makes sense. Rock on.

[AzureEyes]

It'll help with Polar's latency. I may actually pick Polar up now!


Sent from my iPad using Tapatalk

[LudvigC]

It'll help with Polar's latency. I may actually pick Polar up now!

Hi,

sorry, but Polar won't be delay compensated, at least not right now. Even though it has the pitched signal has an inherent latency, there is a dry signal which doesn't. The dry signal has a manually set delay parameter (continuous) which makes things tricky. Since there's no good way to get a true latency report from the device, we chose not to implement delay compensation for it.

/ LudvigC (product designer)

[Timmy Crowne]

I'm hoping this can be used on any channel. Some sounds have a slower attack and need to be pulled ahead so that things groove together well.


Sent from my iPhone using Tapatalk

[Loque]

After reading RE need to provide infos about their delay and the problem with dry/wet i am curious which device i can trust and a bit confused. A while back i had to check some devices dry/wet details on latency and found something in the manuals. TG they delayed the dry signal. I am wondering that Polar doesnt do it or how it will work on full wet as a send fx or in parallel channel...

[esselfortium]

I'm hoping this can be used on any channel. Some sounds have a slower attack and need to be pulled ahead so that things groove together well.


Sent from my iPhone using Tapatalk

You can manually set each channel's delay amount in the back of the rack, so yep

[AzureEyes]

It'll help with Polar's latency. I may actually pick Polar up now!

Hi,

sorry, but Polar won't be delay compensated, at least not right now. Even though it has the pitched signal has an inherent latency, there is a dry signal which doesn't. The dry signal has a manually set delay parameter (continuous) which makes things tricky. Since there's no good way to get a true latency report from the device, we chose not to implement delay compensation for it.

/ LudvigC (product designer)

Guess I won't be buying it! I'll be using Soundtoys Crystallizer and Eventides H3000!


Sent from my iPad using Tapatalk

[JiggeryPokery]

After reading RE need to provide infos about their delay and the problem with dry/wet i am curious which device i can trust and a bit confused. A while back i had to check some devices dry/wet details on latency and found something in the manuals. TG they delayed the dry signal. I am wondering that Polar doesnt do it or how it will work on full wet as a send fx or in parallel channel...

I may have some misunderstanding here, Scuzzy or someone can chime in and correct me or expand, but here's my layman take.

With a dry/wet control you have, predictably, both a dry signal and processed wet signal: internally, only the wet would normally be subject to any processing latency. So especially if using a device in parallel, you'd likely not want the dry signal subject to PDC. This is why PDC can be confusing and potentially cause more problems than it solves.

You can test this easily with VMG-1. On Chenille, for example, there's no latency when fully dry, but based on the patch I tested (the default one I think) VMG-1 didn't report any latency until the dry/wet knob was heading to 75%, because it's only at that point there wasn't enough dry signal for VMG-1 to detect as "latency". But since a chorus is a modulated delay, then VMG-1 can't a show fixed value anyway as it's constantly changing.

And that example highlights the other fundamental problem with describing PDC: if a device reports no latency, some users might think that's an error, when it will often be the fact that a lot of effects are delays. Addng a chorus to an effects chain, for example, adds a chorus delay to the signal. I'm unconvinced how using PDC to "compensate" is actually relevant in that type of scenario. It's a delay, adding latency is the whole point of it!

So in 9.5 Chenille will report no latency even at 100% wet, and this is correct.

So I think unless a device is adding latency on the dry signal (which I would have thought no device should be doing, otherwise it's not what I would consider a dry signal), I wouldn't worry too much if a lot of devices report 0 latency: PDC I think is really aimed towards effects devices that require lookahead or provide a lookahead option, or complex FFT processing, and where wet is 100%, ironically, devices like the complex pitch-shifting aspects of Polar, and not things that inherently add intentional delay to a signal, like delays and choruses.

RE's have always been required to state their latency, but it wasn't enforced, even, it seems, by PH in their own early products . And of course any (3rd party) SDK1-based products that are incorrect can't be updated even if the developer is still active.

[Creativemind]

Andrew Scheps doesn't explain what Delay Compensation is here but explains how it's necessary when doing Parallel Compression as it adds phasing issues. I've copies the video to start at the bit where he talks about Parallel Compression but he talks about delay compensation at 22:39.

[friday]

You can manually set each channel's delay amount in the back of the rack, so yep

Nice, so you can set the delay to minus to pull ahead or do you have to set a delay on all other channels? Would really love to see a picture of the PDC settings back of the rack?

[bunja]

.

[bunja]

Tutorial using delay in reason for polar

[bunja]

.

[bunja]

.

[bunja]

use a delay with it

[bunja]

.

[bunja]

Is the way in the video the best way .can you use the vmg ?

[bunja]

To delay compensate polar i mean

[sonicbyte]

Guys, if you check for instance the latest update of:
https://shop.propellerheads.se/product/t00b-distortion/

It reads on the update's description: Now supports PDC

This means each RE should be updated by their developers to work with PDC ? I thought this was a general thing that Reason could solve by itself with this feature.

[bunja]

It'll help with Polar's latency. I may actually pick Polar up now!

Hi,

sorry, but Polar won't be delay compensated, at least not right now. Even though it has the pitched signal has an inherent latency, there is a dry signal which doesn't. The dry signal has a manually set delay parameter (continuous) which makes things tricky. Since there's no good way to get a true latency report from the device, we chose not to implement delay compensation for it.

/ LudvigC (product designer)

Guess I won't be buying it! I'll be using Soundtoys Crystallizer and Eventides H3000!


Sent from my iPad using Tapatalk

there waaay more expensive

[esselfortium]

Guys, if you check for instance the latest update of:
https://shop.propellerheads.se/product/t00b-distortion/

It reads on the update's description: Now supports PDC

This means each RE should be updated by their developers to work with PDC ? I thought this was a general thing that Reason could solve by itself with this feature.

REs were supposed to be reporting delay already, but 9.5 has revealed that some weren't reporting accurately and needed to be updated.