Integrating Reason with VCV: I tried every way so you don't have to

Reason and VCV Rack are meant to play with each other, but neither is eager to. My ideal DAW would be Reason, with front-patched VCV modules living directly in its rack.

It’s a shame integrating them is still pretty difficult. However, I have already used VCV successfully to record songs in Reason, and integrated Reason 11 instances to live VCV performances.

In this thread, I will summarize my efforts so far, good and bad, to use them together. I won’t go into detail about each one - I will only do so upon request. Otherwise, it’d take me days to write this post, and I am not even sure it’s of interest to anyone at all.

Why Reason?

Fantastic synths, excellent sample playing and mangling tools, great effects, nice player devices (especially for live generative music), all that for a low CPU cost.

Reason’s studio rack metaphor uses pairs of stereo audio cables and monophonic CV/Gate cables, making a distinction between both kinds of cables. Rack devices can be connected to Reason’s fantastic mixer, and all have an implied connection to its serviceable (if aging) traditional sequencer.

While its rack can be kinda coerced into being a modular environment, it’s primarily sold as a DAW for EDM and Hip-hop: the devices favor being “instant satisfaction” black boxes, with hardwired built-in filters, envelopes, and effect sections, generally offering at most a modulation matrix to tinker with their internals, or swappable sub-modules.

Reason supports VST2 since 2017, and is available itself as a VST3 since 2019.

Hosted vs. side-by-side

There are three different theoretical ways of going about this: hosting Reason in VCV, hosting VCV in Reason, and running both side-by-side.

Because both Reason and VCV Rack are capable of everything DAW-y, I want them to be able to send each other signals bidirectionally, and not simply use one one as a synth or as an audio effect within the other.

When Reason is used as a VST, you can no longer access its fantastic mixer, nor its sequencer, which, while it is a neglected aspect of Reason, it still quite decent.

When both are used side-by-side, there’s no more total recall - you have to keep in sync your save in both programs.

For live improvised generative jams, I find embedding Reason within VCV vastly superior - for now. It might change once I get to try VCV for DAWs.

For recording a sequenced song, I much prefer the other way around, to be able to make use of Reason’s sequencer and mixer.

Now, let’s review many of our options:

VCV for DAWs (upcoming)

It’s not released yet! I’m mentioning it only because you should be aware it’s coming with VCV 2.0. It will be a commercial product allowing you to run VCV as a VST2 plugin. It’s likely to be the easiest way to host VCV within Reason once it’s available. I will update this thread with any relevant info once I get to try it.

Bridge (deprecated)

Bridge was an experimental VST allowing for a side-by-side setup. 1.x versions of Rack no longer ship with bridge, and while it can still be used if you grab the files from a 0.62 installation, it never was sufficiently reliable to use. You might get lucky, but don’t count on it - expect heavy crackles making it entirely unusable.

VeeSeeVST (non-official, no longer updated)

VeeSeeVST is a fork of an old 0.x version of VCV Rack, that ships with a collection of free modules. It works well, but with multiple drawbacks:

  • It won’t be updated anymore, so any issue is here to stay
  • Import a patch from standalone VCV doesn’t work well
  • Many recent modules won’t ever be available
  • It doesn’t support polyphony
  • It’s slower than 1.x
  • You’re stuck with the old text-only module browser
  • No MIDI out

Where it really shines is when you really just want that one specific eurorack module as a reason rack device. Like just using Clouds as an insert.

Up to you to decide if it’s worth it to use something obsolete until the official solution is out, and if being able to edit your projects long-term matters to you.

VCV Host (recommended)

VCV Host is a commercial module that allows you to run VST plugins. As of September 2020, this is the easiest method.

Before September 2020, Host could only run VST 2.x plugins, requiring the use of hacky wrappers: Kushview Element, Nektarine, vsti3shell.x64.dll. This info is no longer useful, but if you happen upon this post from a search engine looking up non-VCV specific info, it’s still in the edit history - click the little pen button at the top right of my post.

Since the 1.2.0 update to Host, not only it can load VST 3.x plugins, it contains Reason-specific tweaks - @Richie allowed me to beta test the Host update, and worked on eliminating UI bugs that were prevalent when using wrappers.

Two laptops side by side


I have not tried this option, but this would be the simplest way to run them side by side without messing with loopback software. Plus, if you’re performing using laptops, you probably don’t have enough CPU for a loopback-based solution anyway. So if you got 'em, and also have a sound interface with enough I/O, just add a pair of cheapo USB <> MIDI converters and never bother with software again.

Loopback-based solutions

Loopback drivers are essentially virtual devices that route their inputs to their outputs, but that masquarade as normal hardware as far as your audio software is concerned.

To make Reason and VCV communicate, you will need a MIDI loopback driver, and an audio loopback driver.

MIDI loopback: LoopMIDI

I haven’t looked further than loopMIDI for MIDI loopback drivers, because it works perfectly without any annoyance.

Audio loopback: ASIO4All & VB-CABLE

I used to use ASIO4ALL to add VST support to Reason before it added it officially, lol.

You will want to use it with VB-CABLE, which adds a virtual audio interface with 8 channels to Windows.

This setup is reliable, but a bit of a pain to set up.

Audio loopback: Voicemeeter Banana

By the same author as VB-CABLE, Voicemeeter Banana allows for complex routing of virtual audio. The initial setup is challenging, but then you don’t have to tinker with it. This is my current preferred option, as it allows me to route audio to stream with OBS Studio, and has a built-in recorder.

Audio loopback: JACK Audio

I found it a huge pain to set up on Windows, and if this thread doesn’t make it obvious, my tolerance threshold for painful hacked together setups is quite high. VCV has I/O modules for the JACK protocol, but JACK in general is a Linux thing. Absent a JACK I/O device in Reason, you will have to mess up with servers and drivers and config files. Not worth the trouble.

MIDI & Audio loopback: OS X options

I haven’t used OS X in years, so I’m not sure what are the best options anymore. But last I used it, virtual MIDI devices were built into the OS, no third party software required, while Soundflower was the easiest way to route audio between programs, but it seems it’s no longer actively updated. @persy suggests using Blackhole instead:

Using more than a single stereo out in Reason

Using Host-XL, you can have up to eight audio outputs, but by default they won’t work - Reason helpfully sums all outputs to 1 and 2 without making it obvious it’s doing that. To enable the remaining outputs, you need to uncheck the “To Main” buttons on the I/O device.

Bypassing the lack of MIDI OUT in Host using Thor

Reason’s player devices are fun to use, but there’s not always a way to send their output as MIDI to the rack. However, you can send monophonic CV! While Reason makes a distinction between CV and Audio, VCV doesn’t. So we just need to use Thor to convert Reason’s CV to audio. If you don’t want to use a Loopback MIDI driver, you can use this technique instead.

To do this, add your player device to a Thor, and reset the Thor. Then program its mod matrix as follows:

Source Amount Destination
Voice Key > Note (Full Range) 100 Audio Output > 3
Voice Key > Gate 100 Audio Output > 4

Now, send audio output 3 and 4 of the Thor to the I/O Device audio output 1 and 2.

There we go! We have a player device sending V/Oct and gate data… but it’s sending it out of tune. To get it in tune, you will need to multiply the V/Oct signal by 0.7. Why that number? Hell if I got a clue, but it works.

Using a host XL, four thors, and a CV Player Tap, you can probably get four note polyphony going too.

In most cases, you will need a track & hold on the V/Oct activated by the gate, otherwise the V/Oct resets while notes are decaying.

Here’s what the setup looks like:


Thanks for reading! Please let me know if you’d like more details about any of these sections. If you use Reason with VCV, be sure to share how you’ve rigged them together and what you did with them.


very thorough write up. i dont use Reason but one thing i’d add would be that Existenial Audio “Blackhole” has become the go to virtual audio driver on osx.


Did you try asio link pro?

1 Like

You can send midi out from your Reason’s player devices using a “CV Player Tap” device.

Nope, I found VB’s options good enough so I stopped my search here for now.

CVPT is super useful to route signals within Reason, but I’m talking about breaking out of Reason to send that data to VCV, preferably polyphonically.

Reason can only do that through its MIDI out device, and that MIDI out device has no MIDI interface selector when used in VST mode - it can only send its MIDI to the VST host, if it supports it, which VCV doesn’t. Hence the Thor workaround.

So, one thing I got wrong above is that you can only send a single stereo audio out due to a wrapper limitation. Turns out that by default, Reason mixes down to the first two channels, and you have to explicitly enable multiple audio out, by unchecking “To Main” in the I/O device. I will update the op with corrected info.

Oh! I see they replace the External MIDI Instrument device for a Midi out device without midi interface! Never notice, i´m on version 10…

But if VCV Host had a CV and GATE outputs maybe it solves the problem…

When used standalone the new MIDI out device still behaves normally, it’s just when used as a VST the dropdown is removed

1 Like

Thanks for the tip.

Maybe you already know “VSTHost” is a free standalone app but open VST3 and have midi in and out.

I used to use VSTHost before Reason had VST support, it’s not exactly user friendly. Since there’s no way to have total recall of parameters I felt it was not worth mentioning compared to the other options. I can confirm it does load VST 3, which its page doesn’t make clear.

Anyway, made a few updated to the OP as I tinker with my setup.

Has anyone mentioned Nektarine from the good folks at Nektar yet?

I just tried it today, and it works straight up surprisingly well. Mind you, i have not tested it thoroughly though, but first impressions are very positive!

As i have tried several other wrappers before in the last year, but ended up with more headaches then fun. Not sure if Nektarine can be obtained for free if you don’t own any Nektar products. But the people at Nektar are very friendly, so maybe an email can do wonders.

1 Like

Oh wow, it supports VST3? I happen to have a P4 but I had mostly ignored this plugin, somehow I was convinced it didn’t support VST3, and I never saw it mentioned in any discussion about the topic of VST wrappers, I’ll have to try it out and report.

Yes it does support VST3, and can run itself as VST2 or/and VST3.

Have you managed to run Reason as an effect accepting audio from Host through Nektarine?

Without the latest beta I cannot run Reason in Effect mode at all, and with the latest beta, I see no way to receive audio from host, I can only use Reason as a Send/Insert for audio produced within Nektarine. That really reduces its utility if it can’t be used as an effect.

1 Like

I have same results here, can not get audio into Nektarine, which i find odd. I can’t say that is for sure the issue, because i have not tried Nektarine with anything else yet then Reason and in VCV host.

I also was not able to get a usable clock sync into Nektarine / Reason.

So as it stands now , it works fine for me as a Reason sound module. And back to the waiting game again for Rack for Daws :slight_smile:

This is incredibly niche info, but as of the most recent Reason update, using both Element and Nektarine in the same VCV patche is much more stable. It used to crash at startup 4 times out of 5, but no longer does. I wasn’t sure if it was crashing for everyone or just for me, because I also have a licensing issue preventing me from writing the license to my computer.

As mentioned above, Nektarine cannot run as an effect, so I still need Element, despite the slow UI.

Big shoutouts to the Reason developers who helped me with this issue by leaving my support ticket on read without any reply for 3 weeks. I won’t try to hide I have more love for what their product used to be than for the people trying to monetize this sinking ship.

From today’s livestream: VST3 for host is in the works! So eventually all those wrappers will be unnecessary.


Thank you for mentioning the mysterious vsti3shell.x64.dll!

It surprisingly turns out that, unlike Kushview Element, the mystery dll is able to successfully run Yamaha’s Motif XS/XF/MOXF editors (VST3) as well as allowing them to communicate with the Motif Hardware via USB MIDI. Element on the other hand causes the editor to complain about a Port Open Error as soon as an attempt is made to establish the connection with hardware.

In addition to allowing total recall for the state of the Motif upon loading a VCV Rack patch, a handful of parameters are exposed for CV modulation which normally aren’t able to be modulated by either the Motif’s internal LFOs or MIDI. Cool stuff!

1 Like

Host has been updated to support VST 3!

I had a chance to test beta versions for compatibility with Reason, and the integration is very solid. I have removed the info about using wrappers from the original post (it’s still in the edit history if you ened it), as they are no longer necessary.


Now that the new Host makes it easy to use Reason liberally, there’s one thing about using Reason with VCV I want to point out: it’s a great way to make CPU-efficient patches, so long as you know which devices to use, because VCV’s CPU meter won’t be able to tell you which Reason Racks are eating all your CPU budget.

Past the first VST instance, Reason seems to have no significant per-instance CPU cost. So you can safely use a lot of Host instances containing very few Reason devices.

Reason has been around for 20 years, and while I have misgivings about their current dev practices, there’s one thing you gotta acknowledge about them: they have a solid track record not to kill off their old tech willy-nilly. In fact, I think there’s only really 4 major techs they’ve truly killed: ReWire (favoring VST integration instead), ReBirth (Roland suddenly realized their old 303s and 909s were a license to print money rather than an old embarrasssment), Line-6 amps (some deal with Yamaha fell through), and Balance hardware (but their unmaintained drivers still work).

Almost everything released in Reason 1 is still in Reason 11. And in 2000, the clock speed of your average single-core Pentium III was expressed in MHz, not GHz. In other words: the older a Reason device is, the more aggressively optimized it’s likely to be. On the other hand, some more recent devices - especially third-party rack extensions - are big CPU munchers. For the budget of a single instance of Europa, I could run a dozen of Thors - and Europa sure doesn’t sound 12 times as good as Thor.

Now, if you haven’t used Reason for many years, you might not be sure which devices are old or recent, so here’s a handy list of older devices that are likely to be aggressively optimized.


  • Subtractor
  • Malström
  • Thor (CPU usage depends on submodules used)
  • NN-19
  • NN-XT (In general, using samples is not expensive on the CPU)
  • Dr OctoRex
  • Redrum
  • Kong


  • Every single half-rack effect (RV-7, DDL-1, etc)
  • RV7000 MkII (I am not sure how well optimized the newer convolution mode is)
  • Scream 4
  • BV512
  • MClass series

This is far from being an authoritative and well-researched list, and more recent devices are often well-optimized, but make fewer optimizations that trade-off sound quality for speed. But some third-party offerings have a CPU cost disproportionately incommensurate with the sound quality they offer.