Routing sends in the reason main mixer

[okaino]

I went back through the reason manual to brush back up on delay compensation. I got it down now and realize how i was screwing uo my mixes by bringing the sends back on to the mix channel.

Im in the middle of a mix now and everything is smooth...im at the stage to add my fx with sends.....first thing im noticing is i cant send my send channels to another send ....which i should be able to but it goes against the way delay compensation works.

So my question is how do you guys work around this?

Id rather not but see theres a CLA Epic plugin that would essentially bail me out of this issue outright but its cpu intensive. So im all ears to any other alternatives.

Thanks!

[selig]

I went back through the reason manual to brush back up on delay compensation. I got it down now and realize how i was screwing uo my mixes by bringing the sends back on to the mix channel.

Im in the middle of a mix now and everything is smooth...im at the stage to add my fx with sends.....first thing im noticing is i cant send my send channels to another send ....which i should be able to but it goes against the way delay compensation works.

So my question is how do guys work around this?

Id rather not but see theres a CLA Epic plugin that would essentially bail me out of this issue outright but its cpu intensive. So im all ears to any other alternatives.

Thanks!

Returns as Mix Channels work just fine as long as you're not trying to do parallel type processing with EQ/Compression/Saturation etc. If using Mix Channels as returns you can easily send from that channel - again, sends are more designed for delay/reverb effects.

Not sure exactly what you're wanting to do, but lets say you have a reverb return on a Mix Channel that you want to add some parallel(send) saturation, I would choose to use a Parallel Channel for that.

I'm probably not fully understanding the situation, maybe you can explain exactly what you hope to achieve?

[okaino]

I went back through the reason manual to brush back up on delay compensation. I got it down now and realize how i was screwing uo my mixes by bringing the sends back on to the mix channel.

Im in the middle of a mix now and everything is smooth...im at the stage to add my fx with sends.....first thing im noticing is i cant send my send channels to another send ....which i should be able to but it goes against the way delay compensation works.

So my question is how do guys work around this?

Id rather not but see theres a CLA Epic plugin that would essentially bail me out of this issue outright but its cpu intensive. So im all ears to any other alternatives.

Thanks!

Returns as Mix Channels work just fine as long as you're not trying to do parallel type processing with EQ/Compression/Saturation etc. If using Mix Channels as returns you can easily send from that channel - again, sends are more designed for delay/reverb effects.

Not sure exactly what you're wanting to do, but lets say you have a reverb return on a Mix Channel that you want to add some parallel(send) saturation, I would choose to use a Parallel Channel for that.

I'm probably not fully understanding the situation, maybe you can explain exactly what you hope to achieve?

hmmmmm im going to try it and come back that does make sense though. In general i am using the sends for only reverb and delays.
I want to route my delay sends into my reverbs (sometimes)

So ill repeat it back to make sure i got it. I can break the master section return and bring it up as a mix channel and still benefit from delay compensation, but for me to send the return channel ill need to create a parallel mixer track for that return mix channel to keep playing into the delay compensation.

The return track brought back on the mix channel cant have any additional processing which is why we use the parallel track to make the additional moves.


Is this what youre saying?

[selig]

Returns as Mix Channels work just fine as long as you're not trying to do parallel type processing with EQ/Compression/Saturation etc. If using Mix Channels as returns you can easily send from that channel - again, sends are more designed for delay/reverb effects.

Not sure exactly what you're wanting to do, but lets say you have a reverb return on a Mix Channel that you want to add some parallel(send) saturation, I would choose to use a Parallel Channel for that.

I'm probably not fully understanding the situation, maybe you can explain exactly what you hope to achieve?

hmmmmm im going to try it and come back that does make sense though. In general i am using the sends for only reverb and delays.
I want to route my delay sends into my reverbs (sometimes)

So ill repeat it back to make sure i got it. I can break the master section return and bring it up as a mix channel and still benefit from delay compensation, but for me to send the return channel ill need to create a parallel mixer track for that return mix channel to keep playing into the delay compensation.

The return track brought back on the mix channel cant have any additional processing which is why we use the parallel track to make the additional moves.


Is this what youre saying?

First, you don't need delay compensation on effects based on delay, such as reverb etc. So there's no advantage or loss in using a Mix Channel and in fact to add any processing to a return you would have to use some other option than the built in mixer returns. The trade off is you cannot solo a track and have its effect automatically heard without ALSO hitting Solo on the delay return channel - and ALSO on the reverb channel if you're adding reverb to delay.
Not a big deal, but can be a bit of a pain if you have to do this often.

I would set it up like this, lets say I use Send 1 for a delay and return it on a Mix Channel, and Send 2 for a reverb (doesn't matter if I use Mix Channel or built in returns for this part). On that Mix Channel functioning as the delay return, I add reverb using Send 2. That's it, should be no issue with delay compensation because the latency amounts for a Mix Channel are one batch (64 samples), which WOULD be a problem for a parallel compression or saturation effect. But those extra samples would never be noticed on a reverb or delay unless you were doing some experiment extreme delay looping over long periods of time, and looping back through another send (feedback repeats in the delay itself are not subject to external latency). Make sense?

[okaino]

hmmmmm im going to try it and come back that does make sense though. In general i am using the sends for only reverb and delays.
I want to route my delay sends into my reverbs (sometimes)

So ill repeat it back to make sure i got it. I can break the master section return and bring it up as a mix channel and still benefit from delay compensation, but for me to send the return channel ill need to create a parallel mixer track for that return mix channel to keep playing into the delay compensation.

The return track brought back on the mix channel cant have any additional processing which is why we use the parallel track to make the additional moves.


Is this what youre saying?

First, you don't need delay compensation on effects based on delay, such as reverb etc. So there's no advantage or loss in using a Mix Channel and in fact to add any processing to a return you would have to use some other option than the built in mixer returns. The trade off is you cannot solo a track and have its effect automatically heard without ALSO hitting Solo on the delay return channel - and ALSO on the reverb channel if you're adding reverb to delay.
Not a big deal, but can be a bit of a pain if you have to do this often.

I would set it up like this, lets say I use Send 1 for a delay and return it on a Mix Channel, and Send 2 for a reverb (doesn't matter if I use Mix Channel or built in returns for this part). On that Mix Channel functioning as the delay return, I add reverb using Send 2. That's it, should be no issue with delay compensation because the latency amounts for a Mix Channel are one batch (64 samples), which WOULD be a problem for a parallel compression or saturation effect. But those extra samples would never be noticed on a reverb or delay unless you were doing some experiment extreme delay looping over long periods of time, and looping back through another send (feedback repeats in the delay itself are not subject to external latency). Make sense?

Thanks for getting me to the correct understanding here.

Originally i ran into this issue because i was using dynamic effects with the sends .....and that was an absolute train wreck.

After taking in what you explained i can relax more i was taking the delay compensation thing too serious.... my confidence to mix in reason got screwed up with that issue.

Im in a great spot now and feeling how i should just trying to keep it going consistently.

Thanks again!

[Billy+]

Man these threads through me...

Selig | Giles I would love for you to answer me this.

If I use the default template that includes two reverbs (plate & room) and a echo device but only apply other effects either inline or on group busses and parallel channels do I need to even worry about this stuff?

[okaino]

Man these threads through me...

Selig | Giles I would love for you to answer me this.

If I use the default template that includes two reverbs (plate & room) and a echo device but only apply other effects either inline or on group busses and parallel channels do I need to even worry about this stuff?

you asked Giles but ill tell you no you wont have anything to worry about the way you described.

If you dont understand what Giles was explaining its basically this.... dont use dynamic processors on the sends (unless you are purposely trying to be experimental.) Simple as that! If you never do that youll never have any issues, and youll never have the question i had.

[mbs]

one could also add a line mixer or 14:2 mixer before the send return and add extra effects there and ducking for example...

[jam-s]

If I use the default template that includes two reverbs (plate & room) and a echo device but only apply other effects either inline or on group busses and parallel channels do I need to even worry about this stuff?

[Billy+]

I prefer Bob Marley

[kbard]

I went back through the reason manual to brush back up on delay compensation. I got it down now and realize how i was screwing uo my mixes by bringing the sends back on to the mix channel.

Im in the middle of a mix now and everything is smooth...im at the stage to add my fx with sends.....first thing im noticing is i cant send my send channels to another send ....which i should be able to but it goes against the way delay compensation works.

So my question is how do you guys work around this?

Id rather not but see theres a CLA Epic plugin that would essentially bail me out of this issue outright but its cpu intensive. So im all ears to any other alternatives.

Thanks!

It is fairly simple. I spent numerous days in this, thinking I am doing something wrong etc. I am coming from Cubase etc.

Plugin Delay Compensation DOES NOT WORK on Reason main Send channels in the Reason mixer. Not like it does in Cubase or Ableton or any other host (there it works just fine for the main mixer and Send channels)

But wait a second. Don't jump to conclusion and read their help file to understand this.

So unlike what you'll experience in Cubase, Ableton or any other DAW - in Reason it won't work. I was thinking I was doing something wrong and then it occurred to me to read help file (RTFM).

http://docs.propellerheads.se/reason10/ ... ingle=true

http://docs.propellerheads.se/reason10/ ... ingle=true

Here is a quote from their official help file:

The delay compensation ignores the latency reported by devices connected as Send Effects.

You may think this might be a problem. Especially if you use DSP effects like UAD or similar (like it was with my setup). Well no. Actually. Yes it can be a problem if you use it for parallel etc. in some weird way.

Like Selig pointed out - in practice you won't get into this as you can use parallel(if needed) in different signal point throughout your session. In many different ways.

You may ask so why the hell this isn't working while in other host it's working just fine. Well (short explanation), other host do not offer you routing freedom in a way Reason does. My understanding is that this is architectural design imposed by amazing routing options. Mixers, splitters etc.

So yeah you will kinda have problems with this if you try to use DSP effects in a very weird setup within Reason Send (main mixer), but in every other way practically Reason PDC for now is working just perfect.

Just read help file it will be clearer after that.

[okaino]

I went back through the reason manual to brush back up on delay compensation. I got it down now and realize how i was screwing uo my mixes by bringing the sends back on to the mix channel.

Im in the middle of a mix now and everything is smooth...im at the stage to add my fx with sends.....first thing im noticing is i cant send my send channels to another send ....which i should be able to but it goes against the way delay compensation works.

So my question is how do you guys work around this?

Id rather not but see theres a CLA Epic plugin that would essentially bail me out of this issue outright but its cpu intensive. So im all ears to any other alternatives.

Thanks!

It is fairly simple. I spent numerous days in this, thinking I am doing something wrong etc. I am coming from Cubase etc.

Plugin Delay Compensation DOES NOT WORK on Reason main Send channels in the Reason mixer. Not like it does in Cubase or Ableton or any other host (there it works just fine for the main mixer and Send channels)

But wait a second. Don't jump to conclusion and read their help file to understand this.

So unlike what you'll experience in Cubase, Ableton or any other DAW - in Reason it won't work. I was thinking I was doing something wrong and then it occurred to me to read help file (RTFM).

http://docs.propellerheads.se/reason10/ ... ingle=true

http://docs.propellerheads.se/reason10/ ... ingle=true

Here is a quote from their official help file:

The delay compensation ignores the latency reported by devices connected as Send Effects.

You may think this might be a problem. Especially if you use DSP effects like UAD or similar (like it was with my setup). Well no. Actually. Yes it can be a problem if you use it for parallel etc. in some weird way.

Like Selig pointed out - in practice you won't get into this as you can use parallel(if needed) in different signal point throughout your session. In many different ways.

You may ask so why the hell this isn't working while in other host it's working just fine. Well (short explanation), other host do not offer you routing freedom in a way Reason does. My understanding is that this is architectural design imposed by amazing routing options. Mixers, splitters etc.

So yeah you will kinda have problems with this if you try to use DSP effects in a very weird setup within Reason Send (main mixer), but in every other way practically Reason PDC for now is working just perfect.

Just read help file it will be clearer after that.

Do you find that you use less of the effect level in reason than you would in cubase for mixing?

[kbard]

Do you find that you use less of the effect level in reason than you would in cubase for mixing?

No nope. I was worried when I encountered into this and was thinking that this is wrong, but then in practice it appears as a non issue. For example my UAD reverb plugins introduce 7ms in a path. But that 7ms is a non issue because on sends I would usually use only their Reverbs. You can see 7ms as a "predelay" value so to speak.

UAD compressors, tapes and EQs are generally used on channel insert FX and that is as you are aware perfectly compensated.

But in most cases it turned out that on main Sends I'll either use a chorus, reverb or a delay and that's it. And then again I tend to use Relab reverbs lately and native FX altogether - and they are ale 0 (zero) delay so in fact and in practice it's a non issue. It was only issue in my head when thinking "why I can't do this or that" but when actually making music it's another story.

Where and IF i need parallel compression I then simply use compressor which already has inbuilt dry/wet control so that solves it. I don't use such compressors on Sends but on their insert FX slots.

It really is a non issue for most of the real world scenarios.

If there is a need for some weird setup I could then see myself using Buses and a time align tools and again problem solved.

[okaino]

Do you find that you use less of the effect level in reason than you would in cubase for mixing?

No nope. I was worried when I encountered into this and was thinking that this is wrong, but then in practice it appears as a non issue. For example my UAD reverb plugins introduce 7ms in a path. But that 7ms is a non issue because on sends I would usually use only their Reverbs. You can see 7ms as a "predelay" value so to speak.

UAD compressors, tapes and EQs are generally used on channel insert FX and that is as you are aware perfectly compensated.

But in most cases it turned out that on main Sends I'll either use a chorus, reverb or a delay and that's it. And then again I tend to use Relab reverbs lately and native FX altogether - and they are ale 0 (zero) delay so in fact and in practice it's a non issue. It was only issue in my head when thinking "why I can't do this or that" but when actually making music it's another story.

Where and IF i need parallel compression I then simply use compressor which already has inbuilt dry/wet control so that solves it. I don't use such compressors on Sends but on their insert FX slots.

It really is a non issue for most of the real world scenarios.

If there is a need for some weird setup I could then see myself using Buses and a time align tools and again problem solved.

Got it! Thanks.