So a tool like the VMG-01 sample delay isn't necessary anymore ?platzangst wrote: ↑01 May 2017Many 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.
What is Delay Compensation?
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:
Note I made this image before Reason had PDC to explain why its a bit more difficult in Reason.
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.Voyager wrote: ↑17 Jan 2018I 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 ?
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.Voyager wrote: ↑17 Jan 2018In 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.
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 ?
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.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.
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!
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.
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.
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.
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.Voyager wrote: ↑18 Jan 2018Normen, 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.
-
- Information
-
Who is online
Users browsing this forum: Steedus and 22 guests