What is Delay Compensation?

This forum is for discussing Reason. Questions, answers, ideas, and opinions... all apply.
User avatar
Voyager
Posts: 535
Joined: 21 Dec 2015

16 Jan 2018

platzangst wrote:
01 May 2017
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.
So a tool like the VMG-01 sample delay isn't necessary anymore ?

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

17 Jan 2018

Voyager wrote:
16 Jan 2018
So a tool like the VMG-01 sample delay isn't necessary anymore ?
You still need it with internal routings, Reason only compensates the mix channels going to the mix bus - like all other DAWs. You can still create routings in Reason that can't be resolved by the internal PDC:

Image

Note I made this image before Reason had PDC to explain why its a bit more difficult in Reason.

User avatar
Voyager
Posts: 535
Joined: 21 Dec 2015

17 Jan 2018

normen wrote:
17 Jan 2018
Reason only compensates the mix channels going to the mix bus


And the parallel channels too no ?

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

17 Jan 2018

Voyager wrote:
17 Jan 2018
And the parallel channels too no ?
Yeah, but generally only what happens in the SSL mixer is what I mean, none of the wiring in the Rack is compensated.

User avatar
Voyager
Posts: 535
Joined: 21 Dec 2015

17 Jan 2018

normen wrote:
17 Jan 2018

Yeah, but generally only what happens in the SSL mixer is what I mean, none of the wiring in the Rack is compensated.


I Just tried the following thing, in main channel i use a Legend and in parallel a Kratos 2 oversampled to 4x and lookahead ( texture ) to 0.10ms. Without oversampling i got 20 sample delay and when oversampling i got 83 ( oversampling add 63 sample ).

Now, when i adjust the sample delay to 83 to the main channel i got no phase issue as expected but i notice that if i disable the VGM-01 and enable Reason sample delay it display 63 and i have phasing issue. So it seems reason sample delay isn't take in count the initial 20 sample delay of Kratos 2.

Why ?

So this means if i only use Reason build-in sample delay and have bunch of parallel channels it suffices that Reason sample delay mess the reading on one parallel channel to make its overall use obsolete ?

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

17 Jan 2018

Voyager wrote:
17 Jan 2018
I Just tried the following thing, in main channel i use a Legend and in parallel a Kratos 2 oversampled to 4x and lookahead ( texture ) to 0.10ms. Without oversampling i got 20 sample delay and when oversampling i got 83 ( oversampling add 63 sample ).

Now, when i adjust the sample delay to 83 to the main channel i got no phase issue as expected but i notice that if i disable the VGM-01 and enable Reason sample delay it display 63 and i have phasing issue. So it seems reason sample delay isn't take in count the initial 20 sample delay of Kratos 2.

Why ?

So this means if i only use Reason build-in sample delay and have bunch of parallel channels it suffices that Reason sample delay mess the reading on one parallel channel to make its overall use obsolete ?
From what you say it sounds like the Kratos limiter doesn't report the correct latency so Reason can't counter-act. The VMG actually measures the latency by sending a test signal.

User avatar
Voyager
Posts: 535
Joined: 21 Dec 2015

17 Jan 2018

normen wrote:
17 Jan 2018

From what you say it sounds like the Kratos limiter doesn't report the correct latency so Reason can't counter-act. The VMG actually measures the latency by sending a test signal.



In deduction, Reason built-in delay compensation isn't reliable since it affect all the parallel channels. What i mean is that if a device can't report a correct latency i understand that you can compensate sample delay from the back of the mixer channel, but before compensate you must know you got some phasing going in there.
So if phasing somehow slipped through your hears you won't compensate at all and end up with some phasing anyway. So to avoid this and contrary to what i've said before VGM-01 is still unavoidable.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

17 Jan 2018

Voyager wrote:
17 Jan 2018
In deduction, Reason built-in delay compensation isn't reliable since it affect all the parallel channels. What i mean is that if a device can't report a correct latency i understand that you can compensate sample delay from the back of the mixer channel, but before compensate you must know you got some phasing going in there.
So if phasing somehow slipped through your hears you won't compensate at all and end up with some phasing anyway. So to avoid this and contrary to what i've said before VGM-01 is still unavoidable.
Well thats the case in all DAWs then, minus the bit where you can manually fix it like in Reason :) I guess since Reason didn't make use of the reported delay value before PDC its more likely for REs that bugs in that regard slipped through the cracks due to the lack of testing possibilities.

User avatar
Voyager
Posts: 535
Joined: 21 Dec 2015

18 Jan 2018

If i only use the wet signal when parallel channel i'm not supposed to get any phasing issue right ? Doesn't phasing happend only when there is some of the dry signal blend with the wet or i'm wrong ?

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

18 Jan 2018

Voyager wrote:
18 Jan 2018
If i only use the wet signal when parallel channel i'm not supposed to get any phasing issue right ? Doesn't phasing happend only when there is some of the dry signal blend with the wet or i'm wrong ?
Yeah, its what happens when you play the same audio twice with a slight time difference. Or at least the phasing we mean here. Audio always "phases" in some way. Comb filter effect is probably the more correct name for this kind of phasing.

User avatar
Voyager
Posts: 535
Joined: 21 Dec 2015

18 Jan 2018

normen wrote:
18 Jan 2018

Voyager wrote:
18 Jan 2018

If i only use the wet signal when parallel channel i'm not supposed to get any phasing issue right ? Doesn't phasing happend only when there is some of the dry signal blend with the wet or i'm wrong ?


Yeah, its what happens when you play the same audio twice with a slight time difference. Or at least the phasing we mean here. Audio always "phases" in some way. Comb filter effect is probably the more correct name for this kind of phasing.


Not sure i got your response in the right way, so you mean that my quote is right ?

User avatar
SH1audio
Posts: 4
Joined: 18 Jan 2018

18 Jan 2018

Voyager wrote:
17 Jan 2018

In deduction, Reason built-in delay compensation isn't reliable since it affect all the parallel channels. What i mean is that if a device can't report a correct latency i understand that you can compensate sample delay from the back of the mixer channel, but before compensate you must know you got some phasing going in there.
But if you don't actually hear the phase cancellation happening, it can't be that bad, right? If something's destructively out of phase, it is VERY noticeable.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

18 Jan 2018

Voyager wrote:
18 Jan 2018
Not sure i got your response in the right way, so you mean that my quote is right ?
Yes

User avatar
Voyager
Posts: 535
Joined: 21 Dec 2015

18 Jan 2018

normen wrote:
18 Jan 2018

Voyager wrote:
18 Jan 2018

Not sure i got your response in the right way, so you mean that my quote is right ?


Yes
ok, by the way when i said "Doesn't phasing happend only when there is some of the dry signal blend with the wet or i'm wrong ?"
what i meant is having the main source channel and its parallel channel with a dry and wet signal ( let's say 50/50 ).

edit : I just made another test, one source channel and its parallel channel with a Echobode "eX simple echo" patch as effect. What i notice is that up to 75% dry/wet, VGM-01 doesn't report any sample delay, from 76% to 100% it report 11060 sample delay. As i said above i though the more wet you blend the less comb filter you get !?..

edit 2 : just found out JiggeryPokery post which explain my scenario above..

Normen, so my quote isn't exact i think, as JiggeryPokery said, except if a device is adding latency intentionally because it's part of its effect, there may be some case were other devices effect set fully wet could still add some unwanted comb filtering. Feel free to correct me if i'm wrong.

JiggeryPokery wrote:
03 May 2017

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! :lol:

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.

Harmen
Posts: 68
Joined: 12 Jan 2018

19 Jan 2018

Processing through a interface with DSP, helps.
of course you would not get the extra effects, but for normal eq, comp and reverb its good.
Via virtual channels; you can direct it back into reason channel without latency. Only the that from the audio interface, so you gotta have a good interface.

good luck.

User avatar
normen
Posts: 3431
Joined: 16 Jan 2015

19 Jan 2018

Voyager wrote:
18 Jan 2018
Normen, so my quote isn't exact i think, as JiggeryPokery said, except if a device is adding latency intentionally because it's part of its effect, there may be some case were other devices effect set fully wet could still add some unwanted comb filtering. Feel free to correct me if i'm wrong.
Well sure, what I said in my first post in this thread always holds. In any Reverb you have lots of comb filter effects - what is "unwanted" is in the eye of the beholder.

Post Reply
  • Information
  • Who is online

    Users browsing this forum: Steedus and 22 guests