VCVRack

VCV Rack.montage un peu sympa.png VCV Rack is a free and open-source cross-platform software modular synthesizer.

Overview

VCV Rack is a free open-source virtual modular synthesizer: multiple modules can be connected to synthesize a sound. By default the software contains several VCOs, LFOs, mixers, and other standard synthesizer modules, however more can be added as plugins through the VCV Rack website.

VCV Rack can be downloaded for free on Linux, Mac and Windows platform, with the source code available at Github.

Version 1.0.0 added a stable API, a multithreading engine and support for polyphonic signals.

Interconnectivity

In addition to the above features, VCV rack can also connect to other hardware and software by outputting analog CV/gate and digital USB or MIDI signals. The software can also connect to other VST plugins though the module host.

On the Satellite Of Love we Expert sleepers ES9 to connect VCVrack to "waveyLines the Eurorack system. Software versions of some of the most popular Eurorack modules on the market is available to download for free.

VCV Rack Basics

This chapter provides an overview of VCV Rack. It is not meant as a tutorial on synthesis with Rack, nor as a guide about all available modules. There are hundreds of modules and tens of developers, thus making it barely possible to track all of them down. Furthermore, the development community is very lively and active, and the modules are often updated or redesigned. The chapter just provides a common ground for the rest of the book regarding the platform, the user interface, and how a user expects to interact with it. It shall therefore introduce the terminology and get you started as a regular user, with the aim of helping you design your own modules with an informed view on the Rack user experience.

So, what is VCV Rack exactly? VCV Rack is a standalone software, meant to emulate a modular Eurorack system. It can also host VST instruments employing a paid module called VCV Host. In future releases, a paid VST/AU plugin version of Rack will be available, to be loaded into a DAW. According to VCV founder Andrew Belt, however, the standalone version will always be free of charge. At the moment, Rack can be connected to a DAW using a module called Bridge; however, its support will be discontinued as soon as the VST/AU plugin version is out. To record audio in VCV, the simplest option is to use the VCV Recorder module.

At the first launch, Rack opens up showing a template patch, a simple synthesizer, where modules can be added, removed, and connected. Patches can be saved and loaded, allowing reuse, exchange, and quick switch for performances.

Modules are available from the plugin store. In addition, they can be loaded from a local folder. This is the case for modules that you are developing and are not yet public but you need to test on your machine. Modules can be divided into a few families:

   Core modules. Built-in modules that are installed together with Rack, for audio and MIDI connectivity.
   Fundamental modules. Basic building blocks provided by VCV for free. These include oscillators, filters, amplifiers, and utilities.
   VCV modules. Advanced modules from VCV. These are not free; their price sustains the VCV Rack project.
   Third-party modules. These are developed independently by the community and are available under the online plugin store. Some of them are free, some of them are paid, some are open-source, and some are not. If you are reading this book, you are probably willing to build new third-party plugins. Some developers provide both a commercial and a smaller free package (e.g. see Vult Premium and Free plugins, which provide exceptional virtual analog modelling of real hardware circuits).
   Eurorack replicas. Some modules available on the store are authorized replicas of existing Eurorack modules. These are free and include, among others, Audible Instrument, Befaco, Synthesis Technology (E-series), and Grayscale modules.

Overview of the System

Figure 3.1 shows a screen of Rack. Its interface is minimal, with just a few items on the top menu and the rest of the screen free for patching. Audio and MIDI settings, different from other music production software, are not hidden in a menu, but are directly available from the core modules.

Figure 3.1: The Rack GUI shows modules mounted on the rack rails. When launching the software for the first time, this template patch shows up, implementing a basic monophonic synthesizer.

Developing with VCV Rack

In Rack parlance, the term “module” refers to the DSP implementation of a virtual Eurorack-style module, while we use the term “plugin” to indicate a collection of modules, all bundled in a folder containing one compiled file, the shared object or dynamic library. Table 4.1 resumes all the terms in the Rack jargon.

Table 4.1: Some common terms in the Rack jargon plugin A collection of Eurorack-style modules implemented in a single dynamic library, developed by a single author or company. The Rack browser lists all plugins and allows you to explore all the modules contained in a plugin. Not to be confused with the term as used in the DAW and VST jargon, where it usually refers to one single virtual instrument. Plugin A C++ struct implementing the plugin. We shall use Plugin in monospaced font only when explicitly referring to the C++ struct. Model A C++ struct that collects the DSP and the GUI of a Eurorack-style module. module Not to be confused with the C++ struct Module. We shall use the generic term “module” to indicate either real or virtual Eurorack-style modules. Module A C++ struct that implements the guts of a module (i.e. the DSP part). ModuleWidget A C++ struct that implements the graphical aspects of a module.

VCV Rack modules are similar to the “plugins” or “externals” or “opcodes” used in other popular open-source or commercial standards in that they are compiled into a dynamic library that is loaded at runtime by the application (provided that it passes a first sanity check). However, Rack modules differ in all other regards. We shall highlight some of the differences in Section 4.1, then we shall go straight to showing the components required to create a module (Section 4.2), and then give an overview of basic APIs and classes used to define it and make it work (Section 4.3). At the end of this chapter, we shall start the practical work of setting up your coding environment (Section 4.4) and building your first “Hello world” module (Section 4.5).

Please note that some programming basics are assumed along this part of the book. You should have some experience with C++. We will recall some basic properties of the language at different points of the book as a reminder for users with little experience in C++ or developers who are used to working with other programming languages. 4.1 Comparison with Other Platforms

Music programming platforms have existed since the 1950s, starting with the first efforts from Max Mathews at Bell Labs USA with MUSIC I. Mathews had a clear vision of how a comprehensive music computing language needed to be designed. For this reason, by the first half of the 1960s, most of the basic concepts were already implemented in his works, with little variations up to these days. Notwithstanding this, in the decades since, there has been a lot of work to design new music computing platforms, to integrate them with new tools, to make them easier to work with, and to update them to the latest programming standards and languages. A lot of these platforms were born in the academic world and are open-source, usually based on C or C++ (think about Pure Data, Csound, SuperCollider, etc.), while some others are commercial (e.g. Steinberg’s VST and Apple AU). Others were born in an academic context but later taken as a full-fledged commercial project (e.g. Cycling ’74 Max/MSP).

VCV Rack is a commercial project with an open-source codebase, which makes it quite different from the others.

4.1.1 Audio Processing

All the aforementioned music platforms comprise a client application where audio processing objects can be loaded and executed. The client application is made of several parallel tasks, managing audio streams, the user interface, handling network connections – for remote audio (Gabrielli and Squartini, 2016) or for licensing and updating – and more. The musical objects usually do the fun stuff. The term “musical object” is just an umbrella term we need here for generalizing all musical programming platforms. In Pure Data, these objects are called externals, in Csound opcodes, and in VST plugins. In Rack, a plugin is rather a collection of objects, and these objects are often called modules, although the proper name for us programmers is Models.

All musical platforms are based on the concept of dynamic linking of dynamic libraries (i.e. libraries implementing additional functionalities – effects, synthesizers, etc. – that are loaded in the same virtual address space of the client application).

In all the classical music programming platforms, there is an audio engine that handles audio I/O and schedules the execution of the audio processing objects in an order that depends on their connections. The audio engine periodically invokes a special function that each audio processing object implements. This function, which for now we will simply call the audio processing function, is called periodically for signal processing to take place. The audio processing function feeds the object with new audio data and expects processed audio data to be returned. Of course, this is not mandatory. Some objects only take input data (e.g. a VU meter) and do not process it. Other objects have no audio input, but return audio data (e.g. function generators).

The audio engine period is determined by the data rate (i.e.

The Graphical User Interface: A Quick Introduction

We all recognize how much the look and feel of hardware synthesizer modules influence the user at first sight. This applies to software modules as well. They should look nice, clear to understand, and possibly have a touch of craze together with a “trademark” color scheme or a logo that makes all the modules from the same developer instantly recognizable. Ugly, uninspiring panels are often disregarded, especially in the Rack third-party plugins list, where there’s already so much stuff. A good mix of creativity and design experience makes the GUI catchy and inspiring, improving the user experience (UX).

In this chapter, we will deal with the practical details of creating a user interface. With Rack, the user interface is created in two stages:

   Graphical design of the panel background (SVG file) using vector drawing software.
   Code development to add components and bind them to parameters and ports of the module.

The SVG file is used as a simple background for the panel. All the interactive parts, such as knobs, connectors, and so on, are added in C++. You will be guided in the design of the background file in Section 5.1.

As reported in Section 4.5.2, the whole module is contained into a ModuleWidget subclass widget that collects all the “physical” elements (knobs, inputs, outputs, and other graphical widgets) and links them to the signals in the Module subclass. The widget class fills the front panel with the dynamic components that are required for interaction or graphical components that may change over time (e.g. a graphic display, an LCD display, or an LED). There is a fair choice of components that you can draw from the Rack APIs (see Section 5.2), but in order to design your customized user interface you will need to create new widgets. This last topic is postponed to Chapter 9. 5.1 Generating SVG Files with Inkscape

All modules require one background image, stored as a scalable vector graphics (SVG) file. The file is stored in the ModuleWidget subclass. SVG is an open-standard vector graphic format required to obtain the best results in terms of graphical rendering with different screen resolutions. A vector graphic file describes the graphics in terms of shapes and vector, while a raster graphic file describes the graphic in terms of pixels. Any graphic file in VCV Rack will require different rescaling for each different monitor or screen resolution. Alternatively, doing this with raster graphic formats such as PNG or JPG requires interpolation, introducing an inherent quality reduction and reducing the readability of the front panel texts.

SVG files can be drawn with several vector graphics applications. However, we will show how to do that using an open-source software, Inkscape. Inkscape is available for all platforms and generates SVG files that are ready to use with Rack. It can be downloaded from https://inkscape.org/ or from the software store available with some operating systems.

We will refer to the graphical design of the ABC plugins. These are extremely simple and clean in their aspect to make the learning curve quick. The ABC plugins adopt the following graphical specifications1:

   Light gray background fill with full opacity (RGBA color: 0xF0F0F0FF).
   A small 5 px-high blue band on bottom (RGBA color: #AACCFFFF).
   Title on top using a “sans serif” font (DejaVu Sans Mono, in our case, which is open-source) with font size 20 (RGBA color: #AACCFFFF).
   Minor texts (ports and knobs) will be all uppercase with DejaVu Sans Mono font but font size 14.
   Major texts (sections of a module, important knobs or ports) will be white in a blue box (RGBA color: #AACCFFFF).

Creating the Panel and the Background

First, we need to create a new file in Inkscape (File → New) and set some of its properties. Go to File → Document Properties (or Shift+Ctrl+D) and:

   Make “mm” the Default Units.
   Make “mm” the Units (under Custom Size line).
   Set the Height to 128.5 mm and the Width to a multiple of 5.08 mm (1 HP), according to the width of the module you want to create.

It is suggested to use a grid for better alignment, snapping, and positioning of objects. In the Document Properties, go to the Grid tab, create a New Rectangular Grid, and verify that the spacing for both X and Y is 1 px and the origin is at 0, 0. Checking the “Show dots instead of lines” box is suggested for improved visibility.

Now we have an empty page whose limits are those of our module front panel. We can now create the background as a rectangle (shortcut: F4) of size equal to the page size. Hint: In order to avoid displacement errors, we suggest using snapping, which automatically snaps the rectangle corners to the page corners. To do this, enable the following options: “Enable Snapping,” “Snap bounding boxes,” “Snap bounding box corners,” and “Snap to the page border” (on the “Snap Control” bar).

We can open the “Fill and Stroke” dialog (shortcut: Ctrl+Shift+F) to set the color of the box. You can just input the RGBA color code that we decided at the beginning of this chapter. We also remove any stroke.

Finally, we decided to add a small colored band at the bottom of the panel as our “trademark,” and to make the panel a bit less dull. We create another rectangle (shortcut: F4) and we snap it to the bottom of the page. This time in the “Fill and Stroke,” we set a nice blue color as in the RGBA color code we decided at the beginning of this chapter.

The empty panel looks like Figure 5.1 now.

Figure 5.1: An empty panel of width 12 HP designed with Inkscape.

The Easy Ones

The boring part is over; from here on. we are going to build and test modules!

If you followed the previous chapters, you are already able to compile a module and edit its graphical user interface. In this chapter, we start with coding. The easiest way to take acquaintance with coding with VCV Rack is to build “utility” modules that are functional but do not require extensive DSP knowledge or complex APIs. We are going to set up a comparator module, a multiplexer/demultiplexer (in short, mux and demux), and a binary frequency divider, shown in Figure 6.1.

Figure 6.1: The modules presented in this chapter.