An unofficial guide to the Rack v1 Changelog

Rack v1 is now released. The following is based on my understanding of the new features listed in the changelog.

The Rack v1 changelog is here:


  1. Not all plugins are ready yet for v1 so you will only see some of them in the module browser. Remember to check the Plugin Manager for new modules too (several free and commercial ones have appeared with v1 was released).

  2. Mac users - if you get an OS X security message when you try to run the v1 Rack binary, right click on the Rack icon in the Applications folder and choose ‘open’.

  3. If you want to run Rack 1.0 and 0.6.2c:

  • Windows - Choose a different installation path when you install Rack 1.0.
  • Mac - Rename the new (or old) binary in the Appplications folder.
    The plugin manager will serve up plugins to each as required - you do not need to duplicate or move your plugins folder.
  1. ‘Oops … I installed Rack 1.0 over the top of 0.6.2c and need to get it back.’ Installers are here:

  2. This is not the VST version of Rack. That will be in the next version.

  3. If you have questions about Rack’s performance on your machine read the sections ‘Add Multithreading to Engine’, ’ Add “frameRateLimit” and “frameRateSync” for setting maximum screen refresh rate and to toggle vertical sync’ and ‘Add engine real-time priority setting’ below. Also, read the official manual here:

  4. If you have found a bug or have a feature request the forum is NOT the place to report it. Read this:

  5. Bridge is deprecated and will be replaced with the Rack VST when version 2 of Rack is released. You should be able to use the 0.6.2 version of Bridge.

Add polyphonic cables.

This is big news and I can’t really do it justice here. VCV Rack is not the first virtual modular to achieve this but Andrew Belt has implemented a very elegant solution utilising existing sockets rather than adding new ones. Monophonic modules can be converted to polyphonic (where this makes sense) and signals carried in between polyphonic modules on polyphonic cables or combined/distributed from and to monophonic modules. Cables become thicker, and polyphonic, on request by sequencers, midi inputs etc. This is set with the originating module’s right click context menu. For a developer-focused explanation of polyphonic behaviour in Rack by Andrew see here:

Leonardo Laguna Ruiz (developer of the Vult modules) has a video on polyphony in Rack here:

Expect some tutorial videos on YouTube very soon. I predict a new category of chord generating modules to appear in the near future too.

Polyphony has been a holy grail for some modular aficionados and has started to appear in a few Eurorack modules; by contrast there is a hardcore of purists, who have spent a lifetime with West Coast bleeps and bloops, who are utterly opposed to it. Well … it’s not obligatory! You can carry on patching monophonically to your heart’s content. It is worth remembering too that polyphony necessarily increases CPU usage.

Add multithreading to engine.

This is a poorly understood feature for many users (including myself when I first learnt about it many months ago). I think what many imagine is that modules will be spread thinly across multiple cores, which will be individually ticking over at low usage. That is not what happens.

Adding multithreading does allow you to add more modules to a patch but there is a cost to this. Adding more threads has a considerable effect on power consumption and, therefore, heat generation. If you add more threads you can expect to hear your fans spinning up. As Andrew put it: “Imagine you have 1000 hours of paperwork to do. If you hire 3 other people, the total man-hours is not decreased but increased to maybe 1500 hours, as there is [the] overhead of collaborating with others.”

The details behind the implementation are quite technical and note that multicore modular is a very challenging problem when you operate at single sample latency. DAWs use much larger buffers and VSTs on different threads do not normally cross modulate each other at audio rates.

For the technically curious, you can begin by Googling ‘spinlock’ and ‘mutex’. Look then at this post by Andrew in his Rack v1 Development Blog: Note also that this type of solution was previously implemented in the ‘Rcomian’ fork of 0.6.2 by Jim Tupper, who has an interesting and informative paper on his experiments here:

The bottom line is that you should not enable additional threads until you need them. Specifying additional threads is not a ‘set and forget’ setting unless you are unconcerned about unnecessary CPU/power usage and heat generation.

Note also:

  1. That due to the way multithreading works you will encounter extreme CPU usage with a completely empty patch or a patch with no Audio module if you have multiple threads enabled.
  2. Rack will detect if your CPU supports hyper threading. You are very unlikely to gain any benefit from using more logical threads than the number of physical cores. Performance may even decrease.

Add undo/redo history.


A most welcome addition. The number of steps is unlimited.

Add module expander support.

In Eurorack modules sometimes come with expanders that extend the module. These are wired to the parent module with ribbon cables around the back. Whilst this has been implemented before by Marc Boulé in some of his Impromptu modules it is now in the SDK. Whereas in the Impromptu modules the expander was launched from the parent, it is now launched as a separate module from the module browser.

Add parameter labels, units, and descriptions.

This is a background feature for developers to give parameter information to users. The front end feature is parameter tooltips.

Add parameter tooltips for quickly viewing parameter values.

Very nice feature to quickly see a brief identifier, voltages, frequencies etc for any parameter. This is enabled from the view menu.

Add parameter context menu for entering numerical values, unmapping, etc.

Entering precise values is not really possible on hardware (and, arguably, this contributes something to the sound). Such limitations do not exist in software. It was previously possible to achieve this in Rack by manually editing a module preset in a text editor.

Now it is a simple matter of right clicking on a parameter and entering the value you want.

Change parameter initialization to double-click.

To reset a parameter to default you previously right clicked on it. Now you double click. A parameter can also be initialised from the parameter context menu.

Add ability to Ctrl-click on an input port to clone the existing cable.

Previously you could Ctrl-click on an output port to get an additional cable output; now you can do the same from an input port.

Add module “force” dragging when holding Ctrl.

Rearranging your patch to make space for a new module or to avoid having to drag cables over long distances on screen with a trackpad used to be an RSI risk factor. This is much lessened now.

It is very easy: just Ctrl-click on a module and move it left or right. This will nudge all the modules sideways. If you want to move a module in between existing adjacent modules you will need to Ctrl-drag it into an empty area and then into the middle of the two modules you wish to separate.

Andrew has a demo here:

Add ability to disable modules with a context menu item and key command Ctrl-E.

Disable blocks the signal path dead of whatever is passing through the module; that is, it is not a bypass as can be obtained with the Host FX modules. The disabled module dims in appearance.

Add sample rates up to 768,000 Hz (16 x 48,000 Hz).

Up to 16x oversampling is now available (it was 4x before). There is also a setting for 8x oversampling. Your mileage may vary on how big a patch you can run at very high sample rates but it’s there if you need it now and it does make a difference at times, notably with FM aliasing, filters and saturation.

Overhaul Module Browser with visual previews of modules.

Making well over a thousand modules instantly accessible has been a challenge throughout Rack’s life. Many users were not thrilled at the loss of the v0.5.x module descriptions in the browser in v0.6.x.

This has been addressed in v1 with the new visual Module Browser with the names and descriptions available by hovering over the module faceplates. Such an approach has been seen before in Softube Modular but Rack’s implementation is very slick given that there are vastly more modules available.

Having a way to visually browse for a module you vaguely remember is a definite bonus, especially with the separately scrollable ‘Brand’ and ‘Tag’ browsers working in combination. The ability to add favourites has been removed though and it remains the case that the fastest route to the module you want is probably to start typing its name (if you know it).

Add plugin info sub-menu to module context menu with links to manual, website, source code, etc…

Apart from Rack and the VCV modules main documentation the way to find manuals or any other textual information on modules has been via the links, mostly to GitHub repositories, on the plugin manager page of the VCV website.

GitHub readmes, Wikis and other pages, amongst a smattering of the developer’s own websites, remain the documentation source, but instead of scrolling through the plugin manager page links are now available directly from the right click context module in each module, along with source code links, and the ability to open the plugin’s folder on the host system.

Add factory presets to module context menu if plugin supplies a folder of presets.

The right click context menu preset options are now tidied up into a submenu and automatically populated with factory presets (where there are any).

Add default template patch.

This is more for new users than seasoned ones who will have developed their own templates, but Rack no longer opens up with an empty rack; instead there is a pre-cabled basic subtractive synth patch that will play from the computer keyboard. Onscreen instructions are displayed in a Notes module.

Add menu item to save the current patch as the template.

The directory hierarchy in the Rack data location places the default template in the main directory and patch saves in the ‘patches’ subdirectory. In the past saving a template involved having to manually move and rename a saved patch in order to create it.

Add “frameRateLimit” and “frameRateSync” for setting maximum screen refresh rate and to toggle vertical sync.

This is a very welcome change first implemented in his Rcomian Rack fork by Jim Tupper (and is something that many MacBook users (amongst others) have been using for months now).

Rack will normally run at the default settings that the graphics card and monitor refresh rate reports to it (eg. 70Hz = 70 frames per second (fps)). This can put a substantial load on the GPU, especially when Rack is being run on a Retina or HiDPI screen. Where a computer lacks a discrete GPU and relies on onboard graphics the load can be severe. Dropping the framerate relieves some of this load.

Providing the means to change the framerate can lead to overheating and screen tearing problems if the fps is increased beyond the refresh rate of the monitor. In the (unlikely) event that you want a faster framerate than the Rack default then you will want to set frameRateSync to ‘false’. Google ‘Vsync’ if you would like to understand this in greater detail.

Setting frameRateLimit to lower settings such as 24 or 30 will reduce CPU and GPU usage. You can go lower if you are really struggling, eg. 10fps, but you will begin to have choppy screen redrawing when scrolling, zooming, dragging cables etc…

These changes are made by editing settings-v1.json in your Rack data directory in a text editor. You should not do this whilst Rack is open because Rack will likely overwrite the file again.

Note that It unfortunately remains the case that laptops with a combination of HiDPI/Retina screens, no discrete GPU, and poor thermals including, but not limited to, many models of Apple laptops in the last few years, remain poorly suited to running Rack and this is unlikely to be improved in the future.

Add “autosavePeriod” for setting the frequency of autosaves in seconds.

Another settings-v1.json setting. The default is 15 seconds. As above, avoid editing settings-v1.json whilst Rack is open.

Add textual menu bar, rearranged menu items, removed icons.

Adding a greater number of menu options whilst trying to minimise screen estate wastage has led to the replacement of the icons and sliders of the previous menu bar with text menus. This also helps with narrower Rack windows on screen and may assist localisation in the future.

Make CPU timer display microseconds and percentage instead of millisamples.

When the ‘CPU Timer’ menu option is enabled the audio module still displays a red bar signifying the remaining resource left but the old millisamples display on individual modules has been replaced by a percentage and microseconds readout. The time display indicates the amount of time your CPU takes to advance the state of the module by 1 sample. These changes have been made partly to make them sample rate invariant and in order to accommodate multithreading.

Add engine real-time priority setting.

Giving the Rack engine priority may improve performance and reduce audio glitches. With multicore processors there should be no risk of maxing out the CPU and blocking keyboard or mouse input (something that could happen ten years ago). This type of potential performance boost was first seen in Rack with Squinky Labs’ Thread Booster. If you are interested in their implementation (some of which translates to the v1 implementation), they have further info on it here:

Note that if you are a Linux user you will still need to set Real Time Priority manually. Details on how to do so are in the Squinky Labs document.

Make rack infinite in all four directions.

If you are used to software with an infinite canvas, like Max or Plogue Bidule, you will love this. A great convenience for organising modules and releasing the top vertical and left horizontal constraint.

Add bus board graphic to rack.

For users of hardware Eurorack seeing a bus board in a partially filled Rack for connecting your modules to the power supply will be a familiar sight.

Add key command Ctrl-- and Ctrl-=, or Ctrl-scroll, for zooming the rack.

This convenience is almost worth the price of admission to v1 (actually $0!) alone. In addition to these key commands you can pinch on a trackpad too. Marvellous.

Fix draw order of cable plugs and wires.

In previous versions you could occasionally see a slight weirdness where a cable appeared to cross underneath a connected plug into a port. Many people probably never noticed it but it is fixed now.

Make Gamepad MIDI driver generate MIDI CC instead of MIDI notes for buttons.

A gamepad is arguably more useful for midi parameter control than for entering or playing notes.

Add Numpad keyboard MIDI device.

The ability to enter notes with your keyboard has been present for some time. Now it can be done on a keypad too. This has to be selected on the right click context menu on a midi module.

Fix Unicode user directories on Windows.

A fix for localisation problems.

Add ability to change cable colors in settings.json.

The ability to change cable colours previously depended on use of the Submarine Utilities module. Now the cable colours can be specified in hex (like in HTML/CSS) in settings.json. A list of as many colours as you like can be created; they are stepped through as before by sequential cable clicks on ports. Again, this file should not be edited whilst Rack is running.

The facility in the Submarine Utilities module is certainly not obsoleted by this feature; it offers very flexible cable colour settings without the use of a text editor.

Add -p X flag for dumping a screenshot of each available module.

This feature was designed for the generation of screenshots for the new module browser. It has the potential of other uses such as documentation generation.

Allow user to see changelogs of plugins before updating their plugin library.

When updating the plugin library (the red dot on the menu bar still alerts you of updates) a list of plugins is now available. Where supplied by the plugin developer there may be a link to the changelog for the plugins. Plugin version numbers are displayed on the list too.

Allow user to update individual plugins.

This offers the fine tuning of plugin updates (potentially informed by the changelog facility). It also gives immediate feedback on which plugins have changes and may be worth investigating for new modules, information that shot past in the prior updating procedure and would require a visit to the plugin manager VCV page to review.


Add Audio-16 with 16/16 inputs/outputs.

Previously available as an rcm module, this doubles the size of the Audio module, which is very useful for those with large external audio interfaces.

Add CV-MIDI, CV-CC, and CV-Gate for sending MIDI to external devices.

Much requested since the early days of Rack, MIDI can now be sent out to external hardware or via internal midi routing to other audio software on your computer. All your exotic sequencing tools and complex generated CVs can now be used outside of Rack, a very exciting possibility.

The three new modules are functional mirror images of the existing MIDI in modules.

Add MIDI-Map for mapping MIDI CC parameters directly to Rack parameters.

Another much requested facility module controls in Rack can now be mapped to MIDI controllers in much the same way as this is achieved with plugins and DAWs. This is particularly useful for certain modules that lack CV controls on parameters you wish to modulate. You can now, for example, map your controller directly to the steps of sequencer.

This is set up via the new MIDI-MAP module. Click a slot there to activate it and then adjust the control in Rack, and the control on your MIDI controller (or vice versa) to map the parameter. A coloured square will appear next to the parameter on the module to indicate this.

Add polyphony to MIDI-CV.

Now that polyphony is available in Rack the changes to this module allow you to set the polyphony mode (Rotate, Reuse, Reset and MPE) and the number of voices (up to 16). Using many voices will increase CPU usage.

Add MPE mode to MIDI-CV.

For those with the exotic new generation of MIDI controllers, such as ROLI devices, Rack can now utilise the control data they produce. Not owning one myself an explanation of how this works would be better supplied by somebody who does.

Add “Panic” button to all MIDI modules to reset performance state.


MIDI has a tendency to flood excessive data or to get stuck in ‘MIDI note on’ state when a device is removed. This can be reset with the Panic button.

Plugin API

Explaining these new features is over my pay grade. Request info from a dev.


Somebody who thoroughly understands open source licenses would be better placed to explain these license changes. You can read about the current license here:


Looks very nice, added to the bottom of If you’re really feeling bored, screenshots for some of the odd features might be easier to explain than words.

I love the statement



Thanks Andrew. Will make some updates in the morning. Re the microseconds, what I don’t understand is what it measures ? Latency cost ?

The time it takes for your CPU to advance the state of the module by 1 sample.


ctrl-= typo?

That’s from the changelog, not my text. Consistency I guess ‘-’ and ‘=’ are at the bottom of the keys, ‘_’ and ‘+’ at the top.

1 Like

Various updates now made. Thanks for the additional info. I will try to add a few screenshots later.


So as long as you’re not running on battery, or with poor thermals (ie. as long as you use a gaming laptop or a desktop), it’s basically a given these will get used…

Does this start to open the door to low-res/lo-fi video processing?

The ask to end all asks: is this based off a file, and configurable by end-users?

In a literal sense that is true.
Weird though, I always associated the - and + characters for zooming out/in and not _ and =.

1 Like

I already have a “What’s New in 1.0” video ready. Just waiting for the release…


Do you think? I certainly won’t (and I’ve been using the Rcomian fork for months on both laptop and desktop). Why heat up your internals without reason when heat will shorten their life?

1 Like

Considering I can’t run on less than 2 threads right now if I want anywhere near reasonable latency, I’m definitely not the best case study by any means.

That being said, I wonder if the v1 implementation gets saved on a per-patch basis, or as a global?

1 Like

It’s global.

1 Like

Is it my imagination or have there been considerable improvements with the graphics? It runs so much quicker and smoother on my linux nvidia laptop with v1, a lot more responsive.

Not a clue, sorry.

Not configurable as far as I can see. If you delete/rename the relevant .svg Rack crashes. I guess you could replace it instead but it would be overwritten on the next update.

IIRC there have been non-multithread related performance improvements, yes.

Excellent work doing a roundup on all of these changes, much appreciated Nik!


Wonderful preview for those of us not inclined to reading changelogs! Thanks.


I have edited the intro and added a mini-FAQ for questions that are coming up on FB.


Definitely configurable if you change RackBusboard.svg

Don’t know if Andrew would love this idea though.