Upcoming VCV as Plugin - please don't forget Linux

With standalone Rack using JACK with VCV Audio or SkJack,

  • Patches aren’t saved into the DAW project file. You need to remember to launch Rack and open the correct patch with each project file.
  • You can’t use multiple instances of Rack to have one patch per channel.
  • You can’t export offline.
  • The VST version will likely run the engine loop on the same thread as the VST processReplacing() call. With JACK, it’s not even in the same process. This increases latency and decreases reliability.
  • You can’t directly automate parameters with JACK.

oh this community is alive! thx 4 the answers.

Currently I am using Jack, but a plugin would be less a hassle for the reasons above. (although I don’t get the latency issue?)
So happy this is going to happen. Thank you!!!
I was thinking about “DAW-automation”, too. Will I be able to move rack sliders with DAW-automation?

Oh yeah, that’s another reason I’ll add to my list.

1 Like

Just sayin’, LV2 plugins are the most widely format in Linux from what I can gather…

1 Like

Added to list.


Instead of making a new thread, I’m gonna hijack this one to make a little suggestion for the VST:

I like using VCV with Reason (currently syncing them via audio and midi loopback devices) and I’d like for audio, MIDI and CV to move seamlessly and bidirectionally between the two racks. Using a Turing Machine with a Reason Synth, or using a Reason arpeggiator Player Device with VCV sounds, that kinda stuff.

While VSTs support sending MIDI to the host, Reason (as a host) doesn’t support that feature. Any chance to:

  • provide native MIDI out to the VST host, for the DAWs that support the feature?
  • leave in the ability to send MIDI to arbitrary devices within the VST, so we can do that with LoopMIDI and the like?

That will be the case. A “Host” driver will be added to audio and MIDI modules that has in/out. It will be the default driver when new VCV Audio/MIDI are added to your rack.


it is posible with jack via midi or Jack midi DAW to VCV and vice versa

perhaps I m wrong, but that is not needed using jack, jack can remain all the connections (except for some reason jack cant remain the vcv rack connection, improve the jack support in the rack could be great)

I will love that 3000

other question @Vortico, the vst patches will be compatible with the normal version?

You can’t directly choose “VCV VCO-1 Frequency” in your DAW when using VCV Rack through JACK though.

Yes, the .vcv JSON file will be the entire contents of the “VST chunk” saved in the DAW project file. You can save/load patches to/from .vcv format with the VST plugin.


Awesome info, thanks Andrew!
And no pressure! - but is there a roadmap/date when this VCV VST creature might rear its’ head ?

ps. nevermind, found an indicator here:

Is it known yet whether plugin instances will be:

  • Capable of running on separate threads?
  • Have multithreading capability within each instance?
  • Able to have individual sample rates?

Also, is the quantity of Host I/O audio channels known yet?

Note those are development timelines, i.e. when I’ll be working on each bullet point. Release dates are after development.

What do you mean by this?

Not sure. Those are both settings from settings.json, not stored in the patch file. I’ll have to see what needs to be pulled out of settings and placed into a third data structure, called something like instanceSettings.

Sorry, it probably wasn’t worded clearly. Just simply:

One instance > processing on a thread
Another instance > processing on another thread

…though typically with VST this is controlled by the host. I’m aware however of a family of VST plugins working on a “Kernel” model that executes all processing together and controls its own threading (Meldaproduction - https://www.meldaproduction.com/technology/plugin-kernel). If Rack for DAWs is designed to function like a typical VST plugin then the question is irrelevant.

Engine threads will not be shared between plugin instances, meaning that two instances can process module DSP simultaneously if the DAW calls the VST’s processReplacing() on different threads. This is in addition to each instance processing multiple modules simultaneously when >1 engine thread is used.

A funny side note: The GUI code does share the same thread across instances, which is in fact shared with all other VST plugins and the DAW itself. (Because all GUI thread must run on the main thread of a process.)


Just FYI, this isn’t true in all DAWs. For instance, in some configurations, Bitwig and Reaper run the VST in a separate process space altogether; or a separate process space with other VSTs with the same plugin ID; or a separate process space with other VSTs of the same manufacturer. Don’t know if that changes your plans at all, but figured I’d share (since I’ve just been through the experience of trying to get a single open source plugin running VST2, VST3, AU and (with help from the #lad folks) LV2 on mac, windows and linux in many daws).

Also, VST2 support for window resize is inconsistent, charitably, across DAWs. But each of AU and VST3 have their own problems too, I found. It’s all a bit messy to be honest…

Will the plugin-enablement code be GPL3 mixed license also?

Thanks for your efforts!

Yeah, Reason is another one that sandboxes plugins in processes.

No, Rack for DAWs will be proprietary.

a crazy idea came to my mind, @Vortico , can the VST rack keep the ability to connect through Jack?

it will to you the vst advantages that you mentioned and still allowing the Linux audio modularity

Yes, all modules and audio/MIDI drivers in Rack will be available in Rack for DAWs.


Heya folks. FWIW, some brief thoughts relating to some of the points raised about JACK above;

  • The de facto method of session management for managing files relating to a project, given the “inverted DAW” nature of JACK, is (these days) the NSM API. I’d recommend the RaySession implementation as it’s robust and actively developed.
  • “CV” patching for parameter automation (formerly an LV2 feature) is now available in JACK2 via the port metadata feature, and there has been some adoption of the technology. More information can be found on this linuxmusicians.com post. There are certainly rough edges and gaps in the ecosystem as it stands (i.e., sequencing & recording), but it’s worth a mention.
  • JACK port metadata has also allowed for MIDNAM information to be presented on MIDI ports (formerly possible with just LV2), with Carla adding this recently. Not a full system for passing parameter names between apps yet, but a start.
  • falkTX has done some next level things in the last year or so with Carla and session management. They recently did a short talk at Sonoj, JACK/NSM Applications in Carla and Carla as Wine plugin, which touched on using VCV Rack within Carla (tl;dw: NSM support in VCV Rack would make using it easier). Their longer Past, Present and Future of the JACK Audio Connection Kit talk was also rather insightful.