Voxengo Premium Membership - All Voxengo Plugins For a Fixed One-Time Fee
Forums     Plugins     Crunchessor Stereo Sidechain in Sonar 6

This topic was created before release of the latest product version, and it may contain details irrelevant to this version.  Replying is disabled for this topic.

Hey guys,

There's a lot of confusion about stereo sidechaining in S6, so I thought I'd write up this short tutorial.

There are multiple ways to have true stereo sidechains in Sonar.

One way used by the twistedlemon.nl sidekick plugin is to have "virtual sidechain channels" (or "universal sidechain" as the db-audioware plugs call them - those plugs allow this as well), like this:

trigger -> compressor in bypass mode (only sends out trigger info to virtual sidechain) -> mix out

programme -> compressor (gets trigger info from virtual sidechain) -> mix out

However this isn't always totally reliable.

Another way is to split your stereo programme, and send the left channel to the first instance of a mono-sidechain plugin, and the left channel of the trigger goes to the other channel of that first instance.  The same thing happens with the right channels:

trigger left -> Comp1 trigger input

programme left -> Comp1 mono input -> Mix left out

trigger right -> Comp2 trigger input

programme right -> Comp2 mono input -> Mix right out

But then, changing the settings in one plugin instance doesn't change the settings in the other instance.  Not good if you like good hands-on control.

Another way is to use a surround channel.  This is the best way to do it in Sonar 6.  This is how to do it, step by step:

1.  Create a surround bus in your project (right click on the bus pane and "Insert Surround Bus")

2.  Call the bus something recognizable, like "crunchessor sidechain"

3.  Go to your programme track pane.  This is the track that's going to get ducked.  Set the output to our "crunchessor sidechain" bus we created in Step 1.

4.  Open the surround panner for your programme (by right-clicking on the track pane's surround panner and selecting "Open Surround Panner")

5.  In there, make sure the channels L and R have numbers 0.0 next to them.  Do this by changing the angle, focus, and width.  It should be so by default.. but just in case, here are the settings I needed: Angle 0.0, Focus 100.0, Width 60.0

6.  Go to your trigger's track pane.  This will be the track that will be triggering the ducking.  Set the output to our "crunchessor sidechain" bus.

7.  In the trigger's surround panner, make sure you get the numbers next to Ls and Rs to 0.0.  Do this by setting the correct Width in the panner.  I set my width to 240.5 (I couldn't hit 240 :-) ), Angle to 0.0, Focus to 100.0.  Make sure the crosshair is still up on top.  You can also get the Ls and Rs levels to 0.0 by using the settings Angle -180, Width 120, Focus 100, but then the triggers will be swapped: the left trigger channel will trigger the ducking of the right programme channel and vice versa.  You don't want that.

8.  Go to our bus, "crunchessor sidechain".  Insert Crunchessor as an FX bin.

9.  Open the Crunchessor control.  You will notice there are 4 tabs with channel names and a fifth tab called Surround Bridge.  Those 4 tabs are four separate instances of Crunchessor.

10.  In the Surround bridge, use these settings:

(Plugin #): 1 (Left input): Left (Right input): Left Surround (Linked): Yes (Enable): Yes

(Plugin #): 2 (Left input): Right (Right input): Right Surround (Linked): Yes (Enable): Yes

(Plugin #): 3 and 4 - leave everything unchanged except for (Linked): No (Enable): No.  This will turn off the 3rd and 4th instance of the plugin.

11.  Now go to the first tab, which should read "L / Ls" (in that order, NOT "Ls / L").  Use this setting for the Crunchessor's sidechain: SC: R.  This setting will propagate to the second instance of Crunchessor ("R / Rs").  It means that your trigger is the trigger channel you have panned to the surround back, in step 7.

12.  Set up all your settings as you wish.  True stereo ducking.

13.  One more problem: we still have the trigger in the surround back.  Even if you just mix down to stereo, the back signal will leak down to your front mix.  We need to cut it out in the signal chain right after Crunchessor.  To do this we will use Sonalksis FreeG (it's a free download.  I hope you won't mind this advertisement, Aleksey), or any other plugin which can be used to mute (not turn down.. mute) audio.  Insert this plugin as the next FX bin after Crunchessor.

14.  In the Surround Bridge for FreeG, turn off all instances except for the one that's got Left Surround and Right Surround routed to it.

15.  In the Ls / Rs tab, use the Mute button to cut out the trigger signal in the surround back.

Done!


Aleksey,

I saw you saying in another thread ( http://www.voxengo.com/forum/crunchessor/898/ ) that sidechaining using two instances of Crunchessor isn't the best idea.

Does this apply to my "workaround"?

Also, any chances on getting midi control over the crunchessor trigger?

E.G. a note on C3 for left, C#3 for right, note on = trigger, note off = release trigger.  Think this would work well?  Velocity could perhaps control how "far" it gets triggered (normally a compressor gets triggered and untriggered up to ~50 times per second, am I right?  Hard-triggering the compressor would give a totally different sound)


'Two instances' is exactly the 'unreliable' method you've mentioned in your text, so I'm not really interested in implementing it.

As for the MIDI control I do not see a reason for it.  You can have the same functionality easily, by using a MIDI Synth that can play a simple sinewave sound.  You can then route it to side-chain channels of Crunchessor, and have the same exact behavior.  When you playing a note, Crunchessor will immediately start to compress, when you release the note, compressor will relax.

Setup of such chain is harder than having it built-in into Crunchessor, but this way it is much easier for all of us, because I do not think such keyboard ducking is required by many users.  While this will add a burden to Crunchessor's user interface.


Compressor is not triggered 50 times per second - it is 'triggered' continuously, depending on the signal envelope.

Aleksey Vaneev: 'Two instances' is exactly the 'unreliable' method you've mentioned in your text, so I'm not really interested in implementing it.

Hmm.. which method that I've described?

If you mean the surround bus method for Sonar, that doesn't really require you to implement anything?

Aleksey Vaneev: As for the MIDI control I do not see a reason for it.  You can have the same functionality easily, by using a MIDI Synth that can play a simple sinewave sound.  You can then route it to side-chain channels of Crunchessor, and have the same exact behavior.  When you playing a note, Crunchessor will immediately start to compress, when you release the note, compressor will relax.

Aleksey Vaneev: Setup of such chain is harder than having it built-in into Crunchessor, but this way it is much easier for all of us, because I do not think such keyboard ducking is required by many users.  While this will add a burden to Crunchessor's user interface.

It would be a way for Sonar users to have stereo sidechaining without doing all I have described.  You can send midi straight to inserts in any track.  However I think they have to be recognized as instruments, and not effects.

Also with another "VSTi effect" that you could put in the trigger's FX chain that would *send* midi notes when ducking is required, you could have something that would require no sends/etc.  This would be more reliable than "virtual channels" (like e.g. twistedlemon.nl or db-audioware), and wouldn't require you to make complicated sends. (notably, surround mixing does slow Sonar down somewhat.  I don't know how it works with Nuendo/SX, but remembering how much SX was slower than S6, I would think it's similar)

The question is whether MIDI is updated often enough in hosts to be of use when you need serious precision.

I know real-life MIDI wouldn't be fast enough: baudrate/bytelenght/(length of note on and off in bytes) = 31250/8/(3+3) = 651.0416666...

This might not be the great idea after all :(

Cheers,

D.


I meant 'virtual side-chain channels' is not a reliable way.  Real side-chain channels is the best way.
This topic was created before release of the latest product version, and it may contain details irrelevant to this version.  Replying is disabled for this topic.