Reason 12.5 introduces full support for and integration with VST3 plug‑ins.
The recent Reason 12.5 update introduced support for VST3 plug‑ins. Let’s go over what this means and take a fresh look at plug‑ins in Reason in general. Quick recap: VST plug‑ins can be used in the standalone Reason app, but not when you’re using the Rack as a plug‑in within another DAW. Plug‑ins are integrated into the Rack as modular devices, similar to the built‑in instruments and effects. They are hosted inside a special device with connection points for CV and audio.
Available VST plug‑ins appear in Reason’s browser, within the Instruments and Effects categories. They are listed after the built‑in devices and grouped by manufacturer. If you already had plug‑ins enabled, you’ll most likely now see more choices populating the list. I was delighted to see the (VST3‑only) Roland Cloud instrument collection appear in my list for the first time. I also noticed that two of each of the Arturia V‑Collection instruments were now being shown, because I have both the VST2 and VST3 versions installed on my machine.
There are a couple of ways you can tidy things up. One is to go to Preferences / Folders and disable either the VST2 or 3 option. If all your plug‑ins have VST3 versions it makes sense to disable the VST2 file paths altogether. This will save you quite a bit of manual sorting and also make Reason launch faster. However, if you have any plug‑ins that are VST2‑only, you need to go with plan B...
In the Windows menu select the Manage Plug‑ins option to open a list of all the VST plug‑ins that Reason has scanned (Screen 2). From here each plug‑in can be individually selected and disabled or enabled. In my case I went through this list and disabled every VST2 plug‑in that has a VST3 equivalent. Unfortunately, there’s no way to select multiple items at once: you have to laboriously select, disable and confirm for every plug‑in in turn. Get the kettle on first.
The other bit of housekeeping I’d recommend is to add pictures to each of your plug‑ins so that you get graphical devices in the browser instead of grey text boxes. To do this, the first time you load any plug‑in into the Rack open its window and click the Screenshot button. I got another cup of tea and did this for all my plug‑ins. It takes a few minutes but I think it’s worth the trouble.
The inspiring thing about how plug‑ins work in Reason is that you can make connections with them directly in the Rack environment.
The inspiring thing about how plug‑ins work in Reason is that you can make connections with them directly in the Rack environment. In addition to Note and Gate inputs, each plug‑in container has eight general‑purpose CV inputs on the rear for patching in modulation from other devices. These can be mapped to just about any parameter on your device (everything that’s automatable). This is a bit of an advantage over regular Rack Extensions which have pre‑defined connections (although you can achieve the same thing by adding native devices to a Combinator).
As well as introducing VST3, the new version upgrades the plug‑in audio output channel count to 64. This is great for drum machine plug‑ins if you want to split each sound out to different processing chains or mixer channels. However, it’s still not possible to send multiple MIDI channels into a plug‑in in Reason for multitimbral operation. Hopefully the extra outputs hint that Reason Studios are working on this too. The other notable limitations are that you can’t send MIDI out of a plug‑in and there are no CV outputs: modulation and sequencing are a one‑way street for plug‑ins in Reason.
Let’s take a deeper look at how to use CV modulation in plug‑ins. In Screen 1 I’ve loaded up Roland’s virtual SH‑101 synth. I’m sequencing the plug‑in from a Matrix unit which is auto‑cabled to the Note and Gate CV connections round the back. Underneath the plug‑in I’ve added a Pulsar modulation device, and on the rear panel (Screen 3) connected the first LFO output to CV input 1 on the plug‑in container.
Routing and scaling of the modulation is set up in the Programmer panel on the front. In the first column you’ll see the list of eight CV inputs. Notice that these are pop‑up selectors, enabling you to choose the same input more than once for patching a single source to more than one parameter. The second column is Amount, determining the depth of modulation. Next is Parameter: this is another pop‑up list, showing every available mod destination. This list can be long, so it’s usually quicker and easier to click the Learn button to the right, then wiggle the parameter you want to modulate on the plug‑in’s interface.
The final setting is Base Value. This is the nominal setting of the parameter before CV modulation is applied. Adjusting the Base Value is the same as moving the plug‑in control on its panel — changes made from either place will be reflected on the other. There can be an offset if it’s a stepped parameter like a switch: adjustments to the Base Value here will only have an effect on the plug‑in at threshold points, but different settings will have an effect on how much modulation it takes to push a parameter to the next step.
In my example, I’ve mapped the Pulsar LFO to the Filter Envelope Amount on the SH‑101, which is not a modulation that is available within the instrument itself. Note that both the Level setting on the Pulsar and the Amount setting on the plug‑in CV Programmer will change the depth of modulation. A nice thing about modulation in plug‑ins is that the changes can be seen animated on the plug‑in control panel.
As a second example I’m using the Pulsar’s envelope generator to modulate the SH‑101’s VCO Pulse Width. The envelope needs triggering, so I’ve used the Spider CV utility device to split the Gate output from my Matrix sequencer, taking this to both the Pulsar Envelope Gate input and the instrument plug‑in’s main Gate connection. The Pulsar’s Envelope output is patched to CV input 2 on the SH‑101. Again, I’ve set a Base Value and modulation amount, and can now see the PWM slider bouncing up and down as the sequence plays.
While we’re going in‑depth on plug‑ins let’s look at the other two key implementations: automation and remote control. There are buttons for both of these in the header bar at the top of any open plug‑in window. The Remote button is for mapping MIDI controller sources to plug‑in parameters. MIDI mapping is built into the native Rack environment, so for regular Rack Extension devices you can use the global Remote Override Edit Mode, or right‑click any control on a device. Plug‑ins are not included in this, so you need to do it by clicking the Remote button then clicking on a plug‑in control. This brings up the familiar Remote Override window where you can assign a control source by manual selection or learning from a MIDI input.
The Automate button lets you pre‑enable parameters for automation editing. Clicking this button followed by any automatable plug‑in control will create a lane for that parameter in the plug‑in’s Sequencer track. However this is a redundant step if you just want to record automation on the fly: you can simply put Reason into Record and perform your parameter changes as you would with any other device. Automation is armed by default for whichever device or track is selected. You can also arm non‑selected tracks by clicking the auto‑arm button to the right of Mute and Solo in the track. After you’ve captured your moves a lane will be created in the main Sequencer automatically.
What’s great is that track automation and CV Rack modulation of plug‑ins work together in Reason rather than fighting each other. Modulation is effectively merged with automation, the latter simply moving the Base Value parameters over time.