Rack development blog

Added SwitchQuantity to Rack v2. Instead of displaying 0, 1, 2, etc for switches, this displays the actual value names instead.


Usage example:

configSwitch(MODE_PARAM, 0, 1, 1, "Engine mode", {"Digital", "Analog"});

In Rack v2, VCV MIDI-CC now supports 14-bit CC commands (i.e. MSB on CC 0-31, LSB on CC 32-63). The Gamepad MIDI driver now generates 14-bit CC commands.

  • Added VCV Audio-2 module which I expect will become the “default” audio interface module in most users’ patches since stereo in/out is usually all that is needed.

  • Made UI tweaks to more closely follow Grayscale’s design. The above screenshot demonstrates all these changes. This includes removing the LED glow/halo effect, brightening up the PJ301M port graphic, and toning down drop shadows.

  • Added fix suggested by @stoermelder to allow plugins to register their own audio/MIDI drivers. For example, it will be possible to create a plugin that installs an audio driver that communicates with an Arduino over a serial connection and exposes CV as a 1000 Hz audio interface. You will then be able to select the “My Custom Arduino Protocol” driver in VCV Audio, and it will handle resampling as needed. Or, register a MIDI device that converts MIDI CC messages to/from your custom Arduino protocol. I’m sure there are many ideas the plugin developer community can invent with this API.

  • Finished “library-izing” Rack. To run the standalone GPLv3 version of Rack, you will launch a small wrapper executable (~100KB) which only contains a main() function that initializes/destroys the Rack application state. The rest of the code is in libRack.so/dylib/dll. Rack for DAWs will come with VST2 plugin binaries (and possibly VST3/AU/AAX later) that link to this library as well. You could theoretically embed this library into your own application and use only the parts you need, such as the plugin loader and engine. However, I have not yet tested this use case in depth so it will not be supported in Rack v2.0.

  • Low-fidelity sample rates will be officially supported and offered in the UI, so plugin developers need to add support for these if their code makes assumptions about possible sample rates. 2020-03-31-114216_1600x900_scrot

  • Rack v2 has switched from using key codes to key names, which correctly handle all keyboard layouts such as AZERTY or Dvorak. Plugin developers should use e.keyName == "q" instead of e.key == GLFW_KEY_Q for checking printable keys. Non-printable keys should still use e.key, e.g. e.key == GLFW_KEY_ESCAPE. More information in the docstrings when Rack v2 source code is released.

  • Overhauled Rack engine threading model. Now all Engine methods are thread-safe and can safely be called from anywhere, with a few additional rules specified in the docstrings. Performance of threading is improved, and after all bugs are fixed with public testing, engine stability will be increased (decreased thread-related crashes).

  • Removed engine pausing. This feature no longer makes sense after the recent engine restructure that allows modules to be processed on the audio thread.

  • Allow disabling smoothing for MIDI-CV (pitch and mod wheel), MIDI-CC, and MIDI-Map.

  • Add several module presets for many Core modules.

  • API

    • Add Engine::getNumModules() and Engine::getModuleIds() to query the Engine’s modules.
    • Module presets beginning with “1_”, “42_”, “001_”, etc do not display those numbers. This allows you to manually order module presets. (Remember to use leading zeros as needed so alphanumeric sorting gives the correct order.)

Added Mouse device to “Computer keyboard/mouse” MIDI driver. This converts your mouse cursor position to MIDI CC 0 and 1 to be used with VCV MIDI-CC. Supports 14-bit MSB/LSB MIDI CC.


The tentative release plan for Rack v2 and Rack for DAWs is the following. By “wait”, I mean “ensure that a certain amount of time passes before the next step”.

  • Continue working on Rack v2 and Rack for DAWs.
  • Once both are “alpha” quality, release Rack v2 source code.
  • Wait at least 4 weeks while testers and plugin developers review the code.
  • Once both are “beta” quality, begin providing development builds of Rack v2. Send Rack for DAWs builds and licenses to testers.
  • Wait at least 2 weeks for users to review the development builds.
  • Once Rack v2 is “stable” quality, release it.
  • Wait at least 2 weeks.
  • Once marketing is ready, release Rack for DAWs.

The following people will be granted beta builds and licenses of Rack for DAWs at no charge.

  • Developers of open-source and commercial plugins on the VCV Library.
  • Developers of freeware plugins at my discretion.
  • A few artists who have tested commercial plugins for VCV in the past.

I am requesting plugin developer feedback for this proposal.


Rack v2 has a new .vcv patch format, which is a compressed folder containing the JSON-serialized patch.json file and other files, such as module patch assets. Read more:

Other changes:

  • Add module whitelist to Module Browser which synchronizes individual modules chosen in the VCV Library.
  • Re-render framebuffers when subpixel offset changes, fixing bug that makes ports and knobs appear slightly offset at certain zoom levels.
  • API
    • Add several convenient filesystem routines to system::.
    • Move all string:: functions dealing with filesystem paths to system::.

This is my (extremely) tentative feature wishlist for Rack v3.

The theme of Rack v3 is “massive performance improvements through architectural overhauls”.

  • Migrate to C++17, or at the least C++14, if most developers’ Apple clang versions support it. (Apple is usually 5 years behind C++ versions.) This will probably end support for Mac 10.7.
  • Compile with AVX. Add simd::float_8 etc.
  • Consider switching from nanovg to Skia or vkvg or Intel fastuidraw or something else. A nanovg API wrapper will be needed.
  • Use better algorithms and heuristics for stepping modules, such as possibly:
    • Store buffers in cables and step modules in sections, as allowed by the cable graph.
    • Add Module::processBuffer().

Recent Rack v2 changelog:

  • Use randomly-generated 53-bit IDs to identify modules and cables in the patch.

Forum tip:

To respond to any of these blog posts, click on the grey timestamp in the top-right of the post and click “New Topic”


Previously you saw switch tooltips and port tooltips added to Rack v2, but now lights have tooltips as well, optionally appearing if the module’s developer has named them with Module::configLight().



Recent Rack v2 changelog:

  • Add a tip window which appears when Rack launches or when choosing “Help > Tips”. Currently there are about 20 tips, which I hope to expand to 50 in upcoming versions. 2020-11-21-073707_1600x900_scrot

  • Use a fuzzy search algorithm for searching modules in the Module Browser.

VCV Rack v2 development is mostly finished, with only restructuring due to Rack for DAWs, review, and testing to be completed. Features and improvements posted in this thread are only a small subset of the complete list of changes. The full changelog will be available when the source code of Rack v2 is released.

However, there is more to be done to Rack for DAWs, the VCV website, the VCV Library, and related business/marketing before Rack v2 and Rack for DAWs can be released. I will continue to use this thread for Rack for DAWs development news.


Recent changelog:

  • Redesign Module Browser with compact layout, adjustable zoom levels, sorting options, intelligent searching, and multiple tag selection.

  • When clicking on a module in the Module Browser and immediately releasing, place the module in the last cursor position in the rack, rather than the current cursor position.

  • When clicking and dragging a module from the Module Browser, fix the mouse handle offset to the center of the module.

  • Check for Library updates every few seconds to avoid needing to restart Rack to check for updates.

  • Add DC blocker setting to Audio modules. On Audio-2, enable it by default.


Since January I’ve been finding it difficult to work on VCV Rack. I know that many of you are anticipating the release of Rack v2 and Rack for DAWs, so I apologize to everyone waiting on these versions. I will continue trying to work on these in the future, but it will be hard for me, emotionally and mentally.

I think v2 will bring the greatest update to VCV Rack yet, with thousands of development hours behind it. It will solve at least half of the criticisms of VCV Rack v1, so the wait will be worth it in the end.

Name restructure

I am not a fan of the name “Rack for DAWs”, so it will be renamed to simply VCV Rack. This bundle will include VST2 and standalone versions for $99 ($149 regular price after release sale). This will solve the issue of needing two separate installers (standalone and VST2) that may have mismatched versions. Professional support of both versions will be included in your purchase of Rack. This avoids the situation where a user who has paid for the VST2 version can’t get proper support for the standalone version.

The free version of Rack will be called Rack Community Edition or Rack CE (I’m not married to this name, feel free to suggest alternatives in a new thread). It will follow the same development process as Rack v1. Source code and builds of Rack CE will be available upon each release. Professional support will not be guaranteed for Rack CE (although bug reports will be appreciated). Rack CE will be released 1-2 weeks ahead of Rack. It won’t be an unstable branch but a release candidate branch for Rack.

Rack CE will be free software (GPLv3), meaning that you have the freedom to run, study, redistribute, and distribute modified copies of the software. I’ve seen some people confuse free/open-source software with open-contribution. VCV Rack is not open-contribution. I encourage you to read The Free Software Definition and The Open Source Definition for the principles and reasons for free/open-source software.

Finally, VCV Rack will no longer use GitHub Issues, since they are a poor solution for customers and non-developers to seek support. All support queries should be sent to contact@vcvrack.com. I might make this change in a few days or wait until Rack v2 is released.


A FAQ about the previous blog post, if anyone is interested:

Why don’t I hire more people to help with VCV Rack 2?

I am flattered that you think I have enough money for that. :slight_smile: I’m mostly joking. I have hired a few developers for various tasks for Rack 2, but the remaining work is mostly architectural and not task-parallelizable.

With that said, there are currently 3 other people (code, design, marketing) working on various aspects of Rack 2. This number can change weekly, depending on the size of tasks.

What do you mean you’re personally “finding it difficult to work on VCV Rack”?

Smear campaigns, emails with personal attacks, false rumors, and hundreds of people trying their best to purposely misinterpret things that I say, really take an emotional toll on me. Only a few Rack users (say 0.1%) engage in this behavior, but with hundreds of thousands of users, that equals hundreds of people finding ways to attack me every day. I’m not bothered by truthful claims about me, those would be my own fault. But the misrepresentations chip away at my desire to serve you, the VCV users.

Also, remember that VCV (the company) is the result of roughly a dozen people’s paid work, not just mine. My bills are greater than what I take home.

P.S. I’m not bothered by people asking “When will Rack 2 release?” It’s a normal question that just expresses curiosity, excitement, or frustration. The answer is that I do not know the release date at this time.

Why is Rack free/open-source but not open-contribution?

VCV is a company like any music software company, such as Ableton, Reason Studios, Image-Line, Cockos, Native Instruments, etc. We share the same goals to bring unique music products to music professionals and hobbyists.

But VCV was founded by a principled free/open-source software supporter. Why should users of software care about their software freedom? There are thousands of articles that answer this question in depth, but in summary, without the freedom to run, review, modify, and share source code, the software you use has the ability to manipulate your choices, and often does. Think of the ways Microsoft Windows, Apple Mac/iOS, or Google’s mobile/web apps (which I know 99% of you use) control how you use your computer and manage your private data. How can you trust them with your private data if you can’t review their source code? You can inspect, repair, replace, and re-solder Eurorack modules you own, so why can’t you do the equivalent with the software you use? This is why VCV Rack, and many VCV-developed modules, are free/open-source software.

So why doesn’t VCV accept free code contributions to Rack itself? I answered this 2 years ago in the Contributing document in Rack’s source code repository. In summary, there are three reasons, each significant enough on their own to support this decision.

  • Contributers should be hired and paid for work accepted into Rack. It’s unfair for developers to work for free to develop VCV’s products.
  • Free contributions usually aren’t practical for stability, compatibility, and longevity. See the above Contributing document for more detail.
  • Modification to VCV Rack usually isn’t necessary. Rack plugins can do everything that Rack can do, since the Rack SDK contains every header file used by Rack. It’s easier to manage plugins each maintained by their own team than a single software product developed by hundreds of people.

Closed-contribution open-source software is very common, and I wish more software companies would release software under this model to improve their customers’ software freedom. If you think closed-contribution implies non-free/closed-source, you are misunderstanding the point of open-source and the meaning of software freedom.

Correction to Rack 2 naming

After feedback and an overwhelming likes-to-participants ratio in a community naming thread, the names of Rack 2 variants will be:

  • VCV Rack Community Edition: open-source standalone version
  • VCV Rack Studio Edition: commercial standalone, VST2, etc version with support

New Module helper methods in Rack 2 and how to use them:

TSwitchQuantity* configSwitch(int paramId, float minValue, float maxValue,
    float defaultValue, std::string name = "",
    std::vector<std::string> labels = {});
TSwitchQuantity* configButton(int paramId, std::string name = "");
TPortInfo* configInput(int portId, std::string name = "");
TPortInfo* configOutput(int portId, std::string name = "");
TLightInfo* configLight(int lightId, std::string name = "");
void configBypass(int inputId, int outputId);

// Examples:

// Switches and buttons are just Params
configSwitch(POLAR_SWITCH, 0, 2, 0, "Polar mode",
    {"Unipolar", "Bipolar", "Inverse unipolar"});
configButton(TRIG_BUTTON, "Trigger");

// Tooltip text on mouse hover
configInput(AUDIO_INPUT, "Audio");
configOutput(MIX_OUTPUT, "Mix");
configLight(GATE_LIGHT, "Gate");

// Short circuit outputs to inputs when bypassed

Rack 2’s API will make writing context menus as easy as possible. After writing 100+ new menu items for Rack features and module context menus, I was finding subclassing to be repetitive and usually unneccessary. In v2 plugin developers will be able to use the following helper functions.


For example, you’ll be able to add this to your appendContextMenu() method.

menu->addChild(new MenuSeparator);

menu->addChild(createMenuItem("Load sample", "kick.wav", [=]() {module->loadSample();}));

menu->addChild(createBoolPtrMenuItem("Loop", &module->loop));

menu->addChild(createIndexPtrSubmenuItem("Mode", {"Hi-fi", "Mid-fi", "Lo-fi"}, &module->mode));

	[=](Menu* menu) {
		menu->addChild(createMenuItem("Copy", "", [=]() {copy();}));
		menu->addChild(createMenuItem("Paste", "", [=]() {paste();}));

This produces the following menu items at the bottom of your module’s context menu.



The source code of VCV Rack 2 is now available to the public! :tada::partying_face::confetti_ball:

VCV Rack Community Edition is free (GPLv3+) software that anyone can review, modify, and share. Our intention is to allow plugin developers to test and migrate their plugins for 6 weeks or more before Rack 2.0 is released, while we collect feedback about the API and finish up its features.

Development builds

Until Rack’s ABI is declared stable, you must only load plugins compiled against your exact Rack version. We will offer occasional builds here.

The default user folder is named Rack2 on all OS’s, so installing Rack 2 will not interfere with your Rack 1 installation.

Bug reports and feature requests are welcome by contacting VCV support. Although we read and appreciate all of your emails about Rack Community Edition, we cannot guarantee responses except for Rack Studio Edition customers when released. Since the issue tracker on the Rack GitHub repository has not been an easy, straightforward, or organized solution for users and customers to open tickets, we have disabled this GitHub feature but will be keeping issue trackers open for open-source VCV plugins (such as Fundamental).

Release schedule

To give sufficient time to plugin developers to migrate their plugins, we guarantee the following minimum dates.

  • Oct 9 at earliest: Rack 2 Studio Edition pre-release licenses available to plugin developers and media.
  • Oct 23 at earliest: Declare Rack 2 API and ABI stable.
  • Nov 6 at earliest: Release Rack 2.0 Community Edition for download and Studio Edition for sale.

Please offer your API feedback before it is declared stable, to ensure that the Rack 2 API is suitable for your purposes.

Plugins not yet updated by plugin developers by the release date will be automatically updated if possible by changing their version to 2.migrated.X.Y.Z and attempting to build against the Rack 2 SDK.


Rack users love factory presets when learning and being inspired by new modules. If you are a plugin developer interested in adding factory presets to your modules, see the new VCV Manual - Module Presets article for a full reference of Rack’s preset feature.


Here is a new Rack 2 build that fixes a few issues with the plugin API (see git log). For ease of migrating, it is recommended for plugin developers to always use the latest Rack SDK.