Mastering the Master Compressor

[EnochLight]

Fantastic new (October 27, 2015) tutorial from Chris Petti (of Dubspot; Knob Theory) on Reason's master bus compressor and compression in general:

Enjoy!

* Also: project files can be downloaded from their website to A/B the difference on your setup. Nice!

[selig]

Oh no, this guy is promoting the wrong way to use side chain in the master compressor. No one seems to get that you are patching the output of the compressor back into itself (including delay), which defeats the purpose of side chain EQ/Filtering.

Oh man, it get's worse: @3:47 he patches the control room output into the key input "to allow the entire mix to side chain itself" - does he not know this is exactly how a compressor works WITHOUT a side chain input? This isn't rocket science here, really makes me wonder who "fact checks" these tutorials…

Seems like almost everyone making tutorials for side chain on the master messes this up. I guess I shouldn't be surprised anymore.

It's really SO easy to do this correctly - aren't this guys supposed to be "experts" here?!?!?

[motuscott]

Often I sidechain the whole mix to my toaster oven. It enhances that Reason sound.

[dana]

To do this to reduce the high-end frequencies in your mix is like using a ferrari to trim your hedge.

[EnochLight]

Is there necessarily a wrong way of doing things, these days though? I just chalked it up to another method to get from point A to B. YMMV, of course. I haven't tried the method above, BTW - I just shared the link since Chris Petti has done a shit ton of tutorials and training in the past. Thought this one was interesting, is all.

[selig]

Is there necessarily a wrong way of doing things, these days though? I just chalked it up to another method to get from point A to B. YMMV, of course. I haven't tried the method above, BTW - I just shared the link since Chris Petti has done a shit ton of tutorials and training in the past. Thought this one was interesting, is all.

There is a standard way of doing side changing filtering such as he describes, and it's as I've described: first split the incoming audio and send it both to the main compressor input AND to the side chain/key input via a filter/EQ. I'm pretty sure it's not done as described in this (and other) tutorials, where you take the OUTPUT of the compressor and use it to feed the key input.

Maybe someone else knows of an application for this, provided you get around the latency issue - it's similar to feedback compression (as opposed to feed forward compression), but those terms describe the inner workings of the main compression circuit, not a method for creating a side chain effect. This is hardly the first time this subject has come around, fwiw. Anyone else care to chime in on this?

[Benedict]

I too wonder if feeding the mix back on itself is the wisest course of action.

Sure his "before" mix is pretty horrid and "after" is good but I would be concerned that the "before" sound like that in the first place - unless of course he did that to embellish his point. It worked but is that the most elegant way to fix a problem?

[EnochLight]

Something that also seems weird - he's using the Control Room to sidechain. Once he sidechain compresses the signal using that Control Room duplicate of the Master, doesn't that signal - now compressed - then get re-fed back into the signal chain via the same loop? Seems that logically this would continue to affect the mix in a negative way.

Or am I missing something?

[selig]

Something that also seems weird - he's using the Control Room to sidechain. Once he sidechain compresses the signal using that Control Room duplicate of the Master, doesn't that signal - now compressed - then get re-fed back into the signal chain via the same loop? Seems that logically this would continue to affect the mix in a negative way.

Or am I missing something?

You're only missing that I've been ranting on that very point in this very thread!

But seriously, that's the "snake eating itself" issue I mentioned previously. Add to that the 64 sample delay incurred with using this method and you've got a double whammy. And this guy is not the first to suggest this approach, when the more logical approach is just as simple and easy to implement. And my approach takes only two cables in total to achieve!

[EnochLight]

Something that also seems weird - he's using the Control Room to sidechain. Once he sidechain compresses the signal using that Control Room duplicate of the Master, doesn't that signal - now compressed - then get re-fed back into the signal chain via the same loop? Seems that logically this would continue to affect the mix in a negative way.

Or am I missing something?

You're only missing that I've been ranting on that very point in this very thread!

But seriously, that's the "snake eating itself" issue I mentioned previously. Add to that the 64 sample delay incurred with using this method and you've got a double whammy. And this guy is not the first to suggest this approach, when the more logical approach is just as simple and easy to implement. And my approach takes only two cables in total to achieve!

D'oh!!!! LOL yes you're right - I totally did miss that part. My bad!

[selig]

Here's the simplest (and most effective) setup for the side chain process described in the video:


Here's the front view, showing the starting point settings (Note: "Solo Hi Band":


Finally, remember to make sure this button is pressed in the master section:

[Flint32]

In this vid, this guy is also using the control room output. Nothing wrong with that.

I guess there is no wrong way of doing things. End result matters the most.

[EnochLight]

In this vid, this guy is also using the control room output. Nothing wrong with that.

I guess there is no wrong way of doing things. End result matters the most.

Good point. @Selig? Care to comment? Perhaps the "snake eating its tale" loopback isn't actually happening in these example case scenarios?

[Flint32]

In fact, this is how the internal sidechain of a compressor works. It listen to the signal that is being fed to it and filters out the un-wanted frequencies (i.e frequencies that we don't want the compressor to be affected by). Because the master compressor doesnt have internal sidechain, we have to get the signal out, filtered and back to the external sidechain input . It is an external loop instead of an internal one

[alex]

In fact, this is how the internal sidechain of a compressor works. It listen to the signal that is being fed to it and filters out the un-wanted frequencies (i.e frequencies that we don't want the compressor to be affected by). Because the master compressor doesnt have internal sidechain, we have to get the signal out, filtered and back to the external sidechain input . It is an external loop instead of an internal one

If I'm not mistaken the "side chain" could be described as a sort of "direct input" for the detector circuit of a "typical" compressor.

I believe a compressor by design employs a copy of the input signal to drive the detector circuit, unless ... another signal is desired, a kick drum for example, in which case the side chain input should be used.

But in both cases AFAIK there is no reason for using the output of the compressor itself to feed again its input back, especially if you have the ability (like in Reason) to split the signal wherever you want. So - no disrespect intended - but I don't get the loop thing in your post.

In my opinion, but I'm not expert here, just sharing a point of view, if you want to compress THAT signal (the one you hear, or an highpass version of it) then you probably do not want to use its compressed version as a reference for the detector circuit (side-chain) of the same compressor or, even worse, a compressed and delayed one! It is not logical if you ask me.

Because it could happen that the more you compress the signal the less the detector should be able to drive the compressor itself once it goes back to its input: that's why - I guess - Selig used the "defeat the compressor" expression for this scenario.

So in order to avoid this it could be advisable to take a copy of the signal you want to use as a reference BEFORE it enters to the compressor and not AFTER it. And avoid any feedback loop as well, I believe.

In Reason "Master Out" and "Control Room" are AFTER the SSL compressor, that's why, in theory, they should never be used for this purpose.

At least, this is what I understand about this topic.
Please correct me if I'm wrong.

With all that said I must add that no matter what theory or reasoning tells to do: right or wrong, if it sounds good it sounds good!

Ciao

[alex]

Good point. @Selig? Care to comment? Perhaps the "snake eating its tale" loopback isn't actually happening in these example case scenarios?

AFAIK Control Room output is an exact copy of the Master output intended for monitor purpose so you can listen a different volume level with it and leave the master one at the "real" (production) output level. Which means the loopback issue is still there I believe.

Ciao

[selig]

In this vid, this guy is also using the control room output. Nothing wrong with that.

I guess there is no wrong way of doing things. End result matters the most.

Have you compared the two approaches? I would say there IS a wrong way for some things but that's just me.

The folks I've pointed this out to in the past have chosen my approach, which is how every device that has internal side chain filtering works (if that's important to anyone).

It's the end result that led me to realize the drawbacks of the above method. But keep on doing your thing if it's working for you, all I suggest is to try both methods so you know the difference.

[selig]

In this vid, this guy is also using the control room output. Nothing wrong with that.

I guess there is no wrong way of doing things. End result matters the most.

Good point. @Selig? Care to comment? Perhaps the "snake eating its tale" loopback isn't actually happening in these example case scenarios?

how can it NOT be?!?

[selig]

In fact, this is how the internal sidechain of a compressor works. It listen to the signal that is being fed to it and filters out the un-wanted frequencies (i.e frequencies that we don't want the compressor to be affected by). Because the master compressor doesnt have internal sidechain, we have to get the signal out, filtered and back to the external sidechain input . It is an external loop instead of an internal one

Not true, and I've shown how to do it!

[selig]

In fact, this is how the internal sidechain of a compressor works. It listen to the signal that is being fed to it and filters out the un-wanted frequencies (i.e frequencies that we don't want the compressor to be affected by). Because the master compressor doesnt have internal sidechain, we have to get the signal out, filtered and back to the external sidechain input . It is an external loop instead of an internal one

If I'm not mistaken the "side chain" could be described as a sort of "direct input" for the detector circuit of a "typical" compressor.

I believe a compressor by design employs a copy of the input signal to drive the detector circuit, unless ... another signal is desired, a kick drum for example, in which case the side chain input should be used.

But in both cases AFAIK there is no reason for using the output of the compressor itself to feed again its input back, especially if you have the ability (like in Reason) to split the signal wherever you want. So - no disrespect intended - but I don't get the loop thing in your post.

In my opinion, but I'm not expert here, just sharing a point of view, if you want to compress THAT signal (the one you hear, or an highpass version of it) then you probably do not want to use its compressed version as a reference for the detector circuit (side-chain) of the same compressor or, even worse, a compressed and delayed one! It is not logical if you ask me.

Because it could happen that the more you compress the signal the less the detector should be able to drive the compressor itself once it goes back to its input: that's why - I guess - Selig used the "defeat the compressor" expression for this scenario.

So in order to avoid this it could be advisable to take a copy of the signal you want to use as a reference BEFORE it enters to the compressor and not AFTER it. And avoid any feedback loop as well, I believe.

In Reason "Master Out" and "Control Room" are AFTER the SSL compressor, that's why, in theory, they should never be used for this purpose.

At least, this is what I understand about this topic.
Please correct me if I'm wrong.

With all that said I must add that no matter what theory or reasoning tells to do: right or wrong, if it sounds good it sounds good!

Ciao

+1 to everything here. To know which you prefer you must try both, I'll leave it at that.

Excellent discussion either way!

[selig]

Just for reference, here's how it's described in an article in SOS, a respected audio journal IMO (and for the record is how I've been describing it):


Figure 1: a) Basic de-essing setup, b) pumping caused by low-frequency energy can be reduced with a high-pass EQ in the side-chain, c) the Compressor plug-in's onboard side-chain EQ section.

http://www.soundonsound.com/sos/jan14/a ... e-0114.htm

Here's another illustration showing the same thing:


https://commons.wikimedia.org/wiki/File ... echain.svg

[selig]

Not to add to any confusion, but there ARE a very few compressors on the market that use "feed back" design (older designs tend to be feed back) instead of the more common "feed forward". Feed back compressors include the 1176, LA-2a, and Neve 2254 compressors among others.



(this graphic doesn't look so good here, see the original here:
https://en.wikipedia.org/wiki/Dynamic_range_compression)

However, as it applies to this thread I do not know how any clones/plugins work with regards to side chain inputs (the originals do not have this feature). But one VERY important distinction to point out here is that there is NO latency in the classic feed back designs, while there IS latency with using the output of the SSL compressor as the side chain input as described in the videos referenced in previous posts in this thread.

[Flint32]

I agree that one drawback of using CTRL room output is that we feed the compressed signal back into the compressor external sidechain.
Would be nice though that the master compressor has internal sidechain with freq filtering built into it so that we can compress only a selected part of the frequency range of the signal instead of the whole freq range .

[selig]

I agree that one drawback of using CTRL room output is that we feed the compressed signal back into the compressor external sidechain.
Would be nice though that the master compressor has internal sidechain with freq filtering built into it so that we can compress only a selected part of the frequency range of the signal instead of the whole freq range .

BUT WE ALREADY CAN!
I've shown how in this very thread, but I guess I wasn't clear enough?

I pretty much ONLY use the Master Compressor this way, especially for bass/drum heavy music. It's the main part of my startup template for Reason (plus Selig Gain/Ozone on the Main Outputs).

[mcatalao]

All this, plus the fact that the Ctrl-Room is a feature by itself, IMHO.

The control room guives you a paralel output of the master, but toggles thought the returns of the mix. It's a great tool to check what's really happening on the send busses, and if you have some room correction to do, you can apply processing over that feed, that it won't be pressed into the audio export (its ok to correct some small dips, and highs that are stubborn to disappear even with acoustic treatment. So if you alter your reference a bit, it cannot affect the audio path so that it isn't rendered.).

If you feed the ctrl-room as a side chain (ok, you can use spiders to split the signal, but if you are going to, why don't do it in the first place???? ) you loose this functionality.

On a side note, my nit pick with control room, is that it doesn't have metronome. It would be good to go from sequencing to mix to master always working with ctrl-room, and you're forced to work with the master direct channel because the metronome is not routed to the ctrl-room. Heck. I don't understand. :/