Could I get some VMG latency advice please?

[Theo.M]

Hi everyone sorry about this but a few things I can't quite work out. I thought this might also be a cool topic to keep tips and tricks for VMG use in, in a variety of different scenarios.

I have been using VMG alot on parallels and inserts where it is very easy to work out the math because I'm using a simple routing structure. (BTW i think props should buy this from Normen and include it in Reason, absolutely defacto standard, as it is essential if using lot's of different RE's with latency. It would at least show they have made some sort of initiative and recognise reason's growing need for PDC).

I must admit I am stuck regarding sends.. I have been avoiding using plugins with any latency on sends except reverbs, where it doesn't matter cause that can just be included in pre delay.. no issue.. but I'm experimenting with a variety of other latent effects on sends, and i can't work out where to place vmg in this case to compensate.
Does anyone know where i would place the VMG if i used say bitspeek on a send? Let's just for the sake of this exercise imagine i have a new project with 2 audio tracks. On one audio track i am using send 1 to send bitspeek to it which is plugged into the main mixer FX return 1. it could be any latent effect but I am just using bitspeek as an extreme example as it has high latency.

the other example would be a tempo delay that has latency on a send.. The timing of the delay wouldn't be exactly right unless it was correctly compensated....

Cheers and TIA!

[submonsterz]

I scratched my head on this too about sends I couldn't figure out how as ya cant use double channels mute original as it wont send then it has to be an active input with volume for the send to work .........................
Another lol for vmg . hopefully Norman can show us all how this can work for that as I gave up trying to figure it out back when I bought vmg and did tests on latencies etc etc to find I couldn't do what I wanted anyhow and have not bothered with vmg for latencies since.

the only way I found which works is record the send then turn it all off and then just add the vmg to the original instrument mixed with send bounce. or as I`ve gone back to doing record then just cut the shit lag from the recorded part of the send bounce. all just a pain in the arse now days after trying other daws that can at least get it half right from the very start with pdc built in :frown: .

[Olivier]

[Had to take down my previous post on this from last night as it was alcohol induced and incorrect]

I think there's an easy fix that works when you have 1 send enabled that introduces latency for a channel.
This is to not route that channel directly to the master output, but to a bus, in which you insert a VMG that compensates for the send. This way the latency compensation is introduced after the signal has been split off to go to the send effect.

When using multiple sends on a channel that have different latencies it gets complicated, but i think its still solvable.
What you have to solve is the fact that the send returns get routed to the master and arrive there different delays.

The solution here lies in delaying every send return by such an amount that every send introduces the same amount of delay.
What rests then is to route the channel that uses that send through a bus that introduces that same latency (like above).


In other words.....
Here's what you have to do for your entire project.

1 Make sure that you put a VMG in front of every active send return (so behind every fx).
This way you can make the total latency through all the individual send FX chains is the same. Make a note of that total latency.

2 Now just route every channel, every bus through a final "delay compensation" bus that introduces that total same latency before delivering the signal to the master.
It does indeed suffice to only route all the channels that use send FX through the final delay compensation bus. But just in case you make a paralell channel somewhere where the primary channel uses send FX, and you forget to route that paralell channel through final delay compensation, why not route everything through that bus for the sake of simplicity ?

I have a project file available to illustrate the concept. I'm pretty convinced it works.

Ofcourse it still applies that this only works with devices that have a fixed latency... Because we can't on the fly measure and alter the VMG settings....

[submonsterz]

[Had to take down my previous post on this from last night as it was alcohol induced and incorrect]

I think there's an easy fix that works when you have 1 send enabled that introduces latency for a channel.
This is to not route that channel directly to the master output, but to a bus, in which you insert a VMG that compensates for the send. This way the latency compensation is introduced after the signal has been split off to go to the send effect.

When using multiple sends on a channel that have different latencies it gets complicated, but i think its still solvable.
What you have to solve is the fact that the send returns get routed to the master and arrive there different delays.

The solution here lies in delaying every send return by such an amount that all sends introduce the same amount of delay.
What rests then is to route the channel through a bus that introduces that same latency (like above)


In other words.....
Here's what you have to do for your entire project.

1 Make sure that you put a VMG in front of every active send return (so behind every fx).
Make sure that the total latency through all the individual send FX chains is the same. Make a note of that total latency.

2 Route every channel, every bus through a final bus that introduces that total same latency before delivering the signal to the master.

I have a project file available to illustrate the concept. I'm pretty convinced it works.

Ofcourse it still applies that this only works with devices that have a fixed latency... Because we can't on the fly measure and alter the VMG settings....

huh???
to use a send its sending the original signal and mixing it with the effect. to allow for latency correction you have to tap the signal of the original after the effect has been applied this cannot happen on a send as you need the original signal to be actively sending to the send it cannot be split and muted.
the only way I found is to record the sent signal then add your vmg to the original that was used to send to the send yes.
latency correction has to be applied to the original and cannot be used before it hits the effect as its the effect plug that has the latency not the original signal. ie if you add a vmg prior to it hitting the effect it is being delayed by vmg then by the plug making it double latency.......................
or I`m not following your method here at all.

[Olivier]

Try my example project. See if it works :
 20150628 [eauhm] General latency correction whith send fx that introduce latency.zip

It did indeed need a bit of mindbending and getting a clear picture of how stuff is actually routed. But try and listen I think this is an elegant solution that works.

[submonsterz]

Try my example project. See if it works :
 20150628 [eauhm] General latency correction whith send fx that introduce latency.zip     

if its reason 8 I cant . so say before I waste time to download if it is please .
if so make you tube vid to show what ya have etc .

[Olivier]

Try my example project. See if it works :
 20150628 [eauhm] General latency correction whith send fx that introduce latency.zip     

if its reason 8 I cant . so say before I waste time to download if it is please .
if so make you tube vid to show what ya have etc .

Which version are you on ?

[submonsterz]

Try my example project. See if it works :
 20150628 [eauhm] General latency correction whith send fx that introduce latency.zip     

if its reason 8 I cant . so say before I waste time to download if it is please .
if so make you tube vid to show what ya have etc .

Which version are you on ?

6.5 and 7.1

[Olivier]

i'll see if i can run 7.1 hang on.. will try to download and install it on my laptop.

[submonsterz]

i'll see if i can run 7.1 hang on.. will try to download and install it on my laptop.

that's too much work for ya send private mail with routing etc ill make easy enough save you downloading and installing .

[Olivier]

i'll see if i can run 7.1 hang on.. will try to download and install it on my laptop.

that's too much work for ya send private mail with routing etc ill make easy enough save you downloading and installing .

Too far into this now.. i want to know if this works R7.1 is installing on my laptop as i type this. Hope it will run.
If i can get it to run i'll build a 7.1 project for you. Stand by please


[update] 7.1 up and running.. building projectfile.. should be there shortly.

[submonsterz]

i'll see if i can run 7.1 hang on.. will try to download and install it on my laptop.

that's too much work for ya send private mail with routing etc ill make easy enough save you downloading and installing .

Too far into this now.. i want to know if this works R7.1 is installing on my laptop as i type this. Hope it will run.
If i can get it to run i'll build a 7.1 project for you. Stand by please

you are a gent thank you.
although its good you are trying to solve these issues I remember back in puf that I asked norman to actually make some demo files and even do a video of the uses and how too`s for this device to which he never did do................................ simple things needed not to be explained but the more in depth and ie this type of dilemma was something he could have done for his customers.

[Olivier]

Ok.. here's a 7.1 test file.

I'll walk you through it:

On insert 1 there's an FX device which introduces a latency of 20 samples.
On insert 2 there's an FX device which introduces a latency of 50 samples.

These are basically combinators with a VMG in it, but its a proof of concept right ? These can be seen as your regular latency introducing FX.

The maximum amount of delay introduced in the Sends is 50 samples.

I then make sure that all send FX have the same amount of latency. Therefor i correct this by inserting an additional30 samples delay into FX Send Chain 1.

This way you can't get phasing issues between whats coming through the FX sends 1 and 2.

Now the only phase difference we have left to correct is that what is coming directly from the mixer channels compared to whats in the FX channels.

This is solved by routing all channels through a final bus in which i introduce a delay of 50 samples.

Play with the FX send 1 and 2 On/Off buttons to see if it introduces phasing.
The effect that you do hear is just a volume increase.
Now disable the insert FX on the final delay compensation and you will hear phasing being introduced by the Sends.

I hope you agree this works.

[submonsterz]

Ok.. here's a 7.1 test file.

I'll walk you through it:

On insert 1 there's an FX device which introduces a latency of 20 samples.
On insert 2 there's an FX device which introduces a latency of 50 samples.

These are basically combinators with a VMG in it, but its a proof of concept right ? These can be seen as your regular latency introducing FX.

The maximum amount of delay introduced in the Sends is 50 samples.

I then make sure that all send FX have the same amount of latency. Therefor i correct this by inserting an additional30 samples delay into FX Send Chain 1.

This way you can't get phasing issues between whats coming through the FX sends 1 and 2.

Now the only phase difference we have left to correct is that what is coming directly from the mixer channels compared to whats in the FX channels.

This is solved by routing all channels through a final bus in which i introduce a delay of 50 samples.

Play with the FX send 1 and 2 On/Off buttons to see if it introduces phasing.
The effect that you do hear is just a volume increase.
Now disable the insert FX on the final delay compensation and you will hear phasing being introduced by the Sends.

I hope you agree this works.

this does seem to work yes by playing with the sends and the latency`s in the vmg`s and using the two compensators seems to work nice one. I shall play more with this routing and kudos as when I tried back when getting vmg I gave up I never looked hard enough obviously.
nice work be testing some more bit later :s0801:
And thank you
but it now gets tricky with a third send added I compensated the other two sends and ya final one with a third send say for instance with a say 70 vmg delay then im getting all sorts of not so good phasing when activating the send 3 on the other channels you made hmmmm.
more fiddling needed its not so simple as adding .

[Olivier]

You're welcome

And here's a drawing to further illustrate what i've done...

Yes.. made it by hand, was quicker.



As you can see you are still free to use insert FX that add latency and compensate as you would normally when using paralell channels.

[submonsterz]

And here's a drawing to further illustrate what i've done...

Yes.. made it by hand, was quicker.

 

read my above added extra about adding more sends to the equation it gets a bit trickier .
check file I put and play with the extra send on other channels certain combos seem to go bit skew wiff to me. or im hearing things akk.

[Olivier]

read my above added extra about adding more sends to the equation it gets a bit trickier .
check file I put and play with the extra send on other channels certain combos seem to go bit skew wiff to me. or im hearing things akk.

Not all sends are the same in regard to their total delay:

You have:
send1: fx@20 compensate@100 total 120
send2: fx@50 compensation@70 total 120
send3: 70... no compensation.
Compensation bus: 120

to fix:

Set the compensation on Sent 1 to 50
set the compensation on 2 to 20
Set the final compensation to 70

You see that you are not touching the FX... just making sure all the chains are the same in delay length

Fixed.

[submonsterz]

read my above added extra about adding more sends to the equation it gets a bit trickier .
check file I put and play with the extra send on other channels certain combos seem to go bit skew wiff to me. or im hearing things akk.

Not all sends are the same:

You have:
send1: fx@20 compensate@100 total 120
send2: fx@50 compensation@70 total 120
send3: 70... no compensation.
Compensation bus: 120

to fix:

Set the compensation on Sent 1 to 50
set the compensation on 2 to 20
Set the final compensation to 70

You see that you are not touching the FX... just making sure all the chains are the same in delay length

Fixed.

another thing to keep in mind and mention is putting anything inside a combi adds 64 immediately to it which you can try device out of combi then measure again inside of combi adds 64 immediately = wrong info sorry it is as scuzzy explains later on the vmg adding this delay on measurement when used from input of combi to out of combi to measure the chain.

[submonsterz]

read my above added extra about adding more sends to the equation it gets a bit trickier .
check file I put and play with the extra send on other channels certain combos seem to go bit skew wiff to me. or im hearing things akk.

Not all sends are the same in regard to their total delay:

You have:
send1: fx@20 compensate@100 total 120
send2: fx@50 compensation@70 total 120
send3: 70... no compensation.
Compensation bus: 120

to fix:

Set the compensation on Sent 1 to 50
set the compensation on 2 to 20
Set the final compensation to 70

You see that you are not touching the FX... just making sure all the chains are the same in delay length

Fixed.

no wonder!!! I`ve all ways been adding the compensation for the next one to all before it too ...
what a dork I am doh :s0959:

[Olivier]

read my above added extra about adding more sends to the equation it gets a bit trickier .
check file I put and play with the extra send on other channels certain combos seem to go bit skew wiff to me. or im hearing things akk.

Not all sends are the same in regard to their total delay:

You have:
send1: fx@20 compensate@100 total 120
send2: fx@50 compensation@70 total 120
send3: 70... no compensation.
Compensation bus: 120

to fix:

Set the compensation on Sent 1 to 50
set the compensation on 2 to 20
Set the final compensation to 70

You see that you are not touching the FX... just making sure all the chains are the same in delay length

Fixed.

no wonder!!! I`ve all ways been adding the compensation for the next one to all before it too ...
what a dork I am doh :s0959:

Yeah.. the idea is to match them

[submonsterz]

if you listen to yours with the click and open another song identical but add 64 to original one and add another one for second send you have like first and add to the final the 64 for the combinators to me its bang on time then as your one sounds a tiny bit out to the click but the extra 64 added to the compensators for the combi adding the 64 I think its then back to bang on yes ?

[submonsterz]

theo will be as happy as me thanks dude you pointed out my big mistake in how I was trying to use this before by adding to everything I cant believe I never noticed that was where I went wrong on this that face palm was a really hurt full one too

[ScuzzyEye]

another thing to keep in mind and mention is putting anything inside a combi adds 64 immediately to it which you can try device out of combi then measure again inside of combi adds 64 immediately

The Combinator doesn't add latency, unless there's external routing. The 64 sample delay is added when the signal chain breaks out of a Combinator, because there's a chance that you'll be feeding the signal back into the Combinator input, and thus making a loop. Most of the time when you break what Reason considers to be a normal, safe signal path, and create one where there's the possibility of a loop, 64 samples are added to keep that loop from becoming a dead lock*.


*Since everything in Reason is guaranteed to complete in a fixed amount of time, the input to a device has to be completely processed in that time. If the input is dependent on the output, it'll take an infinite amount of CPU power to make it finish on time. To get around this problem, when there may be a loop, Reason says, "the input is dependent on the next output batch." A batch in Reason being 64 samples.

[submonsterz]

why would I want to use a blank combinator ? add anything inside it adds the 64...
that's what I see . and nothing if nothing is in it.
are you saying if you do not use the input just the out put it adds nothing ?

[ScuzzyEye]

why would I want to use a blank combinator ? add anything inside it adds the 64...
that's what I see . and nothing if nothing is in it.
are you saying if you do not use the input just the out put it adds nothing ?

It's called Observer Effect, or Probe Effect https://en.wikipedia.org/wiki/Probe_effect. The effect of measuring the system changes the result. Attaching the VMG to a Combinator makes a loop, and introduces the 64-sample delay.

Try this:
Thor* Left output into an Ozone (or some effect with a delay), into a Mix Channel.
Thor Right output into a Combinator with an Ozone inside it, and that Combinator into a Mix Channel.

If what you said is true, the Combiantor adds an additional 64-sample delay, then the two channels shouldn't cancel when one is inverted. But they do cancel completely. So the Combinator isn't adding a delay. The delay it caused by how you hook up the VMG.


*Reset, or some mono patch.