JACK as a Plugin

-in and -out suffixes are now in prerelease. This means you can name both your input and output valley reverb and your JACK patch bay will have a valley reverb-in and valley reverb-out, just like Ardour or non mixer would do.

1 Like

Could be possible add a mute button to each of the channels?


It could, but isn’t this what your mixer is for?

let me expand a little more about my workflow, usually I only mix the drumkits inside the VCV rack, I use renoise (or another DAW) as sequencer, clock and mixer, in the pipeline I could use some external effects like CALF or some vsts through Carla but most frequently the native effects of renoise (compresors, eq, or whatever) even when I own the Vst host of vcv rack because I feel the performance of the vst is better through other ways

however it workflow use multiples desktops (usually one DAW or software per desktop ) and is a little tricky go to other desk to mute channels or get “Solo” for and come back to the vcv rack, and go to the DAW and so and so…

BTW I think a Jack mixer to vcv rack is the next logical step , we (the jack users) happily pay for that.

1 Like

This is what comes to mind when talking about mute switches:


(Mutes from Fundamental wired in to the interface, and an outdated Jack output.)

I’m not sure what JACK has to do with this. It sounds like what you want is a mixing console with two-way sync (probably via OSC+UDP or MIDI CCs) between desktops.


a mixer like “VCV Console” except, the send channels can be connected with external apps via jack or perhaps a hybrid between NON mixer and VCV Console is coming to my mind, about the osc or midi, the midi learn is coming in the next version…

I complete forget Mutes, that is exactly what I mean, thanks!

1 Like

I’ll put it on the “someday” list, although in the interim you can wire an mscHack mixer’s aux lines:



Thank you, you made an amazing module! My problem is I always get a latency with JACK on windows while working between Ableton and VCV Rack. Even in 32sample buffer. I think that’s something in clock relationship form Ableton to VCV. I use .wav file to clocked CLKd module at the high rate from ableton. This is sad because when I’m using Bridge - everything staying in clock pretty well. Maybe I don’t understand JACK working process in Windows or use some wrong settings. This is sad again because I love the perfomance of your module!

I m not sure if it could be useful but take a look of the jack setup of this guide
You backend in Windows must be asio inseat of alsa , I used renoise and vcv rack via jack long time ago and it work pretty nice.
Why not use Linux?

Ableton does not run there, nor does much of anything. Loomer, Pianoteq, Renoise, Bitwig and emulation layers excepted.

Current version does not calculate and report latency information to JACK, so none of the automatic delay compensation utilities know what to do.


Thanks for the answer. Any plans or chance for this feature in the future?

I pushed 0.6.7 of the JACK plugin earlier.

  • Port names have -in and -out bolted on. I did this some time ago but it wasn’t tagged.
  • The manual should be easier to read now.
  • The 8-OUT is finally done.

Latency detection and transport control are probably the lowest hanging fruit for another version. MIDI support is a bit of a doozey since there are various note properties and CCs to pack/unpack.


is this release available in the plugging manager?

1 Like

https://vcvrack.com/plugins.html#jack still at 0.6.6

1 Like

after the last upgrade I m having a big amount of mS in the auxiliary jack modules, see the picture bellow :

I highly recommend using the 8-ins or 8-outs when you don’t need some of the ports. Both of these screenshots have 16 out ports that copy zeroes from JACK and then don’t end up getting used. (There might be an optimization possible by checking if the ports are connected and skipping this copy.)


the firts one is the 0.6.6, and the second is 0.6.7 , from one version to other this has an increase of 10 times of the consumption

however it look very high compared with the past version even for the even in the 8 Rack, it is using much more than the incubus

1 Like

An issue where 8-OUTs were causing conflicts with 8-IN and the default 4/4 module was fixed and is in a pre-release state. Secondly, going forward the modules will test to ensure port names are valid when creating the module. This fixes two things:

  1. Duplicating a module will no longer show port names that cannot be used. The duplicated module will instead show a new set of ports with scrambled names as though you created it from scratch.
  2. Renaming a port no longer results in it “disappearing” when typing. We detect that the name you are typing is not valid and instead refuse to update it, so it will still appear in the patch bay by its old name.

I suppose this also means those using a tool to append two racks will also no longer be able to have conflicting port names–the appended modules will detect the conflict and re-randomize their names.

1 Like

Poking around with the latency detection side of JACK. Thinking of two methods here:

  1. Keep filling up input/output buffers like we are (and as Audio does,) but try to report a full DSP cycle as latency and hope JACK works it out.
  2. Shoe in some thread magic so Rack is blocked until a JACK cycle, we can take the input / process it / output it and so we actually show up with “zero” latency.

May attempt the first and see how it goes since it requires the least effort.

Option 2 might be looked at if option one doesn’t work as well as hoped. Normally DSP code runs this way (where the interface drives the callbacks, which drives the modules/oscillators, not this weird world where Rack just runs as it feels like and then stalls itself when an output fills up a buffer) but emulating it would require doing a lot of multithreaded debugging to ensure ex. deleting the last JACK module doesn’t cause your instance to seize up.

1 Like

I’ve done up some slides for the current state of the JACK plugin and what I will probably end up doing with it:

slides.pdf (117.0 KB)

It’s not incredibly long, but the tl;dr is “probably a crowd fund to handle the upgrade.”

This would probably include externalities like a website/newsletter and dedicated e-mail inbox, since I see people haven’t been reporting certain issues or they are places I don’t go (Facebook.) Trying to maintain infrastructure code + multiple channels of social media + e-mail because its the LCD starts to get, well, job-like.

1 Like