SOLVED! (??) Latency bug; SSL Send FX into Mix channel

[chaosroyale]

A question for the more technically minded users here: simply put - why do the mix channel "combinators" introduce latency when connected to "sends" from the SSL, but ordinary combinators do not.

SIGNAL ROUTING EXAMPLE:

SSL mix channel 1: (a drum sound)
SSL mix channel 1, SEND 1: send to my combinator input
COMBINATOR OUTPUT: return to the SSL master returns.
Result: everything mixes fine, no phasing.

>>> bug version example

SSL mix channel 1: (a drum sound)
SSL mix channel 1, SEND 1: send to my combinator input
COMBINATOR OUTPUT: to input of mix channel 2.

In theory this should mix perfectly, just the same as the SSL FX returns
Result: phasing.

SOLVED - maybe >

Reason automatically recognizes "SENDS" which are routed into mix channels, and adds a 64 sample (one "batch") delay to avoid weird infinite feedback issues. The SSL Returns cannot develop those issues because the dedicated Returns have no separate outs. Therefore SEND > FX > RETURN has no additional latency.

So, how about things like Reverbs and delays into mix channels and busses. Basically, it's not a problem, but see the post linked below for details;

To see the results of an experiment using FX busses and sidechain, with an example wave file, click on the little arrow icon above

[orthodox]

I can't judge what is right or wrong in Reason delay comp architecture. Try to return to that setup where the Master FX Send was routed to a regular Mix Channel (with open Direct Outs). Then open the Mix Channel Programmer, go to the back side of the rack and adjust Delay Compensation samples to 64.

EDIT: I just checked it, I was wrong. There's indeed a significant (~0.1s) delay there.
Seems like Mix Channel cannot be synced when fed from FX Sends.

[Loque]

I think this belongs to unusual routing and is not compensated. You should see this on the backside.

Good to know, that this routing wont work.

[chaosroyale]

What is driving me crazy is that a "normal" combinator does not have this problem, but the Mix channel with the exact same devices has a delay even when returned to the SSL...how is that even possible? Seems like a bug - unless I am missing something.

[artotaku]

Maybe you have feedback loop. Can you check change of setting in Preferences -> Audio -> Render Audio Using Audio card buffer size. If you switch it off, does it change anything?

See article https://help.reasonstudios.com/hc/en-us ... what-s-up-

Returning a send effect on a mix channel. Since the mix channel can be sent to the same send fx, it's a feedback loop (even if you don't enable it).

[orthodox]

What is driving me crazy is that a "normal" combinator does not have this problem, but the Mix channel with the exact same devices has a delay even when returned to the SSL...how is that even possible? Seems like a bug - unless I am missing something.

Mix Channels are the root points in traversing the connection graph when the order of devices and intermediate delays are determined. The circuit where FX Send returns back to a Mix Channel is problematic because all the Send sources must be processed before that particular channel, and it potentially creates a loop because you can enable Send on that channel. It can be done in theory provided that there are no loops, but the current circuit traversal algorithm does not cover such complex scenarios, I guess.

[Carly(Poohbear)]

What version of Reason?

Load up the RE VMG-01 and see what the results are from that (latency checker).

I'm not seeing any Latency issues with your "bug version".
VMG-01 - > Mix Ch 1 - > Send - > Combinator 1(in)- > VMG-01* - > Combinator 1(out) - > Mix Ch 2 - > Back to original VMG-01 - Zero

*The only reason I added a 2nd VMG-01 is with that device you can add your own delay which is handy for testing.

Capture.JPG (214.35 KiB) Viewed 2992 times

Since writing this there have been other comments added.

tested
VMG-01 - > Mix Ch 1 - > Control Room Out - > Back to original VMG-01 - Zero
VMG-01 - > Mix Ch 1 - > Control Room Out - > VMG-01(2) -> Back to original VMG-01 - Zero
VMG-01 - > Mix Ch 1 - > Pre-Send - > Mix Ch 2 - > Control Room Out - > Back to original VMG-01 - 64 samples (which is my buffer size)
VMG-01 - > Mix Ch 1 - > Pre-Send - > VMG-01(2) -> FX Return - > Control Room Out - > Back to original VMG-01 - 64 samples
(also tested with Send (no Pre))

[orthodox]

What version of Reason?

Mine is 10.4.

Load up the RE VMG-01 and see what the results are from that (latency checker).

I'm not seeing any Latency issues with your "bug version".

It might be that by introducing the latency checker you tied the position of the MixCh2 in the processing chain so that it's synced now. Try to reproduce the OP setup. If the latency is there, it can be heard easily, it's about 100ms.

[chaosroyale]

Thanks for the input, guys. It's pretty late where I am, so I will double check tomorrow.

For the record, I am using 9.5.2

I am not using any feedback loops (that shouldn't make a difference to latency anyway - I could introduce feedback from a normal combinator by splitting the output, but the latency would not change in that case)

[selig]

The one "batch" (64 sample) delay is intentional according to past comments from the props on this subject, since you can "send" the signal back to itself when using Mix Channels as returns for sends. I at least wish they would allow "Solo Isolate" for mix channels like the real SSL…

[orthodox]

A simple configuration to test:

[selig]

I am not using any feedback loops (that shouldn't make a difference to latency anyway - I could introduce feedback from a normal combinator by splitting the output, but the latency would not change in that case)

You are creating a POTENTIAL feedback loop when you return a send on a Mix Channel because you can send the return back to the send. As I described above, this is an intentional delay inserted by design, something noted from back when Record was introduced.
Any SSL users immediately wanted to use Mix Channels for returns because this is how we mixed on the SSL, but the latency and lack of solo isolate definitely make this more difficult that it should be IMO.

[chaosroyale]

Yes, that is right, and I agree about preferring to use mix channels on the SSL.

As for the cause of my problem- it is the "single batch delay" as Selig mentioned.

So, this raises another question, which is about using sidechains on the "single batch delayed" channels. I will make a diagram to illustrate and post below.

You are creating a POTENTIAL feedback loop when you return a send on a Mix Channel because you can send the return back to the send. As I described above, this is an intentional delay inserted by design, something noted from back when Record was introduced.
Any SSL users immediately wanted to use Mix Channels for returns because this is how we mixed on the SSL, but the latency and lack of solo isolate definitely make this more difficult that it should be IMO.

[selig]

So, this raises another question, which is about using sidechains on the "single batch delayed" channels. I will make a diagram to illustrate and post below.

I would imagine this would act like a small amount of look ahead, since the trigger for the side chain will come slightly before the audio signal on the channel - could turn out to be a good thing, with the exception that it cannot be manually controlled in any way!

[chaosroyale]

OK. so, it seems that to have phase-perfect parallel processing, you must use the SSL SEND > RETURN, and cannot use mix channels, because they introduce one "batch" of latency.

BUT - for something like Reverb, one batch delay is OK. So, no problem? Well, what about when you combine reverb with a common, timing-critical modulation, like sidechaining. How does that work? Here are the 2 possibilities (compared to a perfect analog desk)

Does Reason use possibility A or B? If nobody knows I will ask the support guys, but I thought you guys might be faster, and might find it useful to think about with your own sound engineering.

EDIT; in this example, the sidechain trigger is a kick drum on channel 3, (i.e. not part of the send-return chain.)

[orthodox]

I believe that any feedback loop that contains a Mix Channel results in such a long delay (it seems to match the current length of the internal processing chain consisting of all devices). Seems like Mix Channels are treated some special way, maybe to allow for larger batches.

Sidechaining generally does not create a loop and any delay problems can be solved easily.

[chaosroyale]

ok, but in my example, the device doing the sidechaining is INSIDE the mix channel. so the question is where in the chain does the delay get added? if the sound is delayed but the sidechain works in sync with the trigger, no problem. if the action of the sidechain is out of sync with the audio from the trigger on a different channel, then that makes it kind of useless.

I believe that any feedback loop that contains a Mix Channel results in such a long delay (it seems to match the current length of the internal processing chain consisting of all devices). Seems like Mix Channels are treated some special way, maybe to allow for larger batches.

Sidechaining generally does not create a loop and any delay problems can be solved easily.

[orthodox]

ok, but in my example, the device doing the sidechaining is INSIDE the mix channel. so the question is where in the chain does the delay get added? if the sound is delayed but the sidechain works in sync with the trigger, no problem. if the action of the sidechain is out of sync with the audio from the trigger on a different channel, then that makes it kind of useless.

Yes, feeding the sidechain input from fx send will delay the signal for the same (large and dependent on all other devices) amount of time, so it's useless.

[chaosroyale]

sorry - maybe I did not explain clearly;

I am feeding the sidechain from another channel, in the example i used a kick drum. the sidechain signal is going directly into the compressor device, which is nested inside the mix channel insert FX.

So my question (which might need Reason Studios to answer because it depends on their specification) is -

Is the delay on the mix channel added at the input, affecting the audio signal before it goes through the insert fx? or is it added at the output, delaying all effects such as my sidechain compression?

ok, but in my example, the device doing the sidechaining is INSIDE the mix channel. so the question is where in the chain does the delay get added? if the sound is delayed but the sidechain works in sync with the trigger, no problem. if the action of the sidechain is out of sync with the audio from the trigger on a different channel, then that makes it kind of useless.

Yes, feeding the sidechain input from fx send will delay the signal for the same (large and dependent on all other devices) amount of time, so it's useless.

[Reasonable man]

https://www.reasonstudios.com/shop/rack ... me-slider/

Try this yoke at various stages in the chain to see if it can solve it . I'm too lazy to test it in this senario.

[orthodox]

Is the delay on the mix channel added at the input, affecting the audio signal before it goes through the insert fx? or is it added at the output, delaying all effects such as my sidechain compression?

First, I'd like to note that the delay of a Mix Channel is not the one we observed in that fx send example (that one was rather the delay of the whole processing chain).
If you mean the compensation delay, then I think that the devices are aligned in the processing chain towards their inputs, and the compensation delay is added afterwards.

EDIT:
I just made a couple of tests feeding the insert fx compressor sidechain from another channel parallel outs and it was perfectly in sync, though I thought using external routing would break delay compensation rules.

That aside, I seem to get into confusion trying to imagine how Reason could work. Most of things can be tested though.

[chaosroyale]

The delay is happening specifically because of this routing;

SSL send > fx combinator > SSL return = no delay

SSL send > fx combinator > mix channel = delay

by using the SSL send and SSL return, there is no delay problem, so when zero delay is important I can use that

however, for something like reverb I much prefer using mixer channels and then bussing all the reverb effects together so I can have a master reverb fader. In that case, if I am not using any sidechain effects, I can just accept 64 samples of delay.

however; when using a sidechain from a kick drum into a compressor inside the reverb combinator, I want the action of the sidechain to sync with the kickdrum input, not be delayed with the audio signal.

Is the delay on the mix channel added at the input, affecting the audio signal before it goes through the insert fx? or is it added at the output, delaying all effects such as my sidechain compression?

First, I'd like to note that the delay of a Mix Channel is not the one we observed in that fx send example (that one was rather the delay of the whole processing chain).
If you mean the compensation delay, then I think that the devices are aligned in the processing chain towards their inputs, and the compensation delay is added afterwards.

[chaosroyale]

I appreciate the responses guys; I might send my diagram over to RS support and ask exactly where in the chain the delay is occuring. I have a feeling it is automatically added to the input of the mix channel when it detects that the input is from the SSL FX sends. If that is the case, then the sidechaining will work because the sidechain will be processed in sync with the trigger, not the "delayed" mix channel audio.

[orthodox]

however, for something like reverb I much prefer using mixer channels and then bussing all the reverb effects together so I can have a master reverb fader. In that case, if I am not using any sidechain effects, I can just accept 64 samples of delay.

That is NOT a 64-sample delay. 64 samples is about 1ms, while there we have an unpredictable delay of 100 milliseconds and more. The delay will depend on how many devices you put in your rack, even those completely unrelated to that send fx.

however; when using a sidechain from a kick drum into a compressor inside the reverb combinator, I want the action of the sidechain to sync with the kickdrum input, not be delayed with the audio signal.

If you feed your sidechain input from a parallel channel, direct outs or a bus, there's no problem. Just don't use the Master Section FX Send outputs for that.

[orthodox]

I appreciate the responses guys; I might send my diagram over to RS support and ask exactly where in the chain the delay is occuring. I have a feeling it is automatically added to the input of the mix channel when it detects that the input is from the SSL FX sends. If that is the case, then the sidechaining will work because the sidechain will be processed in sync with the trigger, not the "delayed" mix channel audio.

I wrote I already tested it. Sidechain signal from FX Send *IS* delayed.

I think the reason is that FX Send signal is formed AFTER all the Mix Channels are done. It can be fed back to the mix, but to that moment, the processing chain is ahead of it by its entire length.