Upcoming VCV as Plugin - please don't forget Linux

VCV Rack
1

I read there will be a upcoming payed version of VCV Rack-host as plugin for DAW integration.

Just wanted to say:
pLeAsE don’t forget about Linux. VCV is a huge in this system.
<3

1 Like
2

Maybe I’m neglecting some use case, but on Linux we might not really need that: we have JACK.

4 Likes
3

yes, If we bought is because we want support the project, not because we need it. actually I m using beside Renoise, (is difficult to say which one is my main DAW ) as vst I afraid we could lose part of that power

4

To my standards, JACK is not a sufficient alternative to a plugin version loaded inside your DAW, even on Linux.

The following (plugin, OS) pairs are confirmed for initial release of VCV Rack for DAWs.

  • VST2 Windows
  • VST2 Mac
  • VST2 Linux

The following pairs will be looked into and might be released after the VST2 plugin is released, although none are currently confirmed.

  • VST3 Windows
  • VST3 Mac
  • VST3 Linux
  • AU Mac
  • AAX Windows
  • AAX Mac
  • LV2 Linux

All builds will be x86_64 (64-bit).

11 Likes
5

wow, then the VST version will be amazing, Just curiosity, what do you find deficient in the Jack pipeline?

6

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.
9 Likes
7

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?

8

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

1 Like
9

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

1 Like
10

Added to list.

3 Likes
11

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?
12

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.

2 Likes
13

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?

14

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.

2 Likes
15

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

ps. nevermind, found an indicator here:

16

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?

17

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

18

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.

19

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.

20

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.)

4 Likes