Rack v1 development blog

(Andrew Belt) #214

Should be fixed.

(Andrew Belt) #215

Added plugin info submenu and factory presets submenu to the module context menu.
If plugin developers wish to include easy-to-access .vcvm presets for certain modules, add them to presets/<module slug> in the plugin directory.

2019-02-17-060806_1600x900_scrot 2019-02-17-070611_1600x900_scrot


Just pulled from v1 and no plugins will build (Template, Fundamental) I get this:

$ make
make: jq: Command not found
make: jq: Command not found
../../plugin.mk:9: *** SLUG could not be found in manifest.  Stop.```

This is in windows.

(Clement Battung) #217

install jq tool in msys2

pacman -S mingw-w64-x86_64-jq

(Sander Stellare Modular) #218

same on mac

(Dmitry Wolf) #219

It builds on my mac.

(Sander Stellare Modular) #220

after installing jq



(Andrew Belt) #222

I’ve written a proposal to allow modules to communicate with modules to their left and right, to add support for expander modules. https://github.com/VCVRack/Rack/issues/1204

(Skrylar) #224

I get the strange impression that I might be one of the causes for this. And/or the ongoing Stages expansion hooplah. :blush:

(Andrew Belt) #225

This feature was requested by Eurorack manufacturers, not plugin developers or users (that I recall).

(Cclark2) #226

I’m curious about the “one .cpp file per module” standard mentioned above. In the plugin tutorial, you recommend this; what advantage do you foresee?

(Andrew Belt) #227

The amount of code in a module is usually about the right size for a manageable source file. It’s not really about the advantages but the disadvantages of other source file organizations.

(Skrylar) #228

There was a rejected PR for Stages that worked around the lack of this behavior, as does my XPND port.

I don’t know anything about the Eurorack manufacturer’s side of things, but it does seem to have been prodded about on the Rack user’s side too.

(Andrew Belt) #229

Added changelog for Rack 1.0.0 in no particular order. Will try to keep up to date until the release.

(Andrew Belt) #230

Fundamental Mixer channel faders now have an extra 6 dB of gain. The labels are now written in dB.


Normally I wouldn’t post news this boring, but I’d like to demonstrate how this is done.

In the VCMixer constructor (the slug used for the recently renamed “Mixer”), each Param is configured with the config method.

VCMixer() {
	// x^1 scaling up to 6 dB
	params[MIX_LVL_PARAM].config(0.0, 2.0, 1.0, "Master level", " dB", -10, 20);
	// x^2 scaling up to 6 dB
	params[LVL_PARAM + 0].config(0.0, M_SQRT2, 1.0, "Ch 1 level", " dB", -10, 40);
	params[LVL_PARAM + 1].config(0.0, M_SQRT2, 1.0, "Ch 2 level", " dB", -10, 40);
	params[LVL_PARAM + 2].config(0.0, M_SQRT2, 1.0, "Ch 3 level", " dB", -10, 40);
	params[LVL_PARAM + 3].config(0.0, M_SQRT2, 1.0, "Ch 4 level", " dB", -10, 40);

The signature of this method is

void Param::config(float minValue, float maxValue, float defaultValue,
    std::string label = "", std::string unit = "",
    float displayBase = 0.f, float displayMultiplier = 1.f, float displayOffset = 0.f)

In the Module::process() method (previously called step()), each fader’s gain is calculated from

float gain = std::pow(params[LVL_PARAM + i].getValue(), 2.f);

Any power can be used, including non-integers, but x^2 “felt” right a year ago when I released this.

The relation between dB and gain is dB = 20 \log_{10} g, and since g = x^2, we have dB = 20 \log_{10} x^2 = 40 \log_{10} x. This means that displayMultiplier should be 40 and displayBase should be 10, except that positive bases are used for exponents (like freq = 2^x), so logarithmic bases are encoded by negating the base. In our case we use -10.

The maximum values of each parameter are such that g = 2 with their respective power.

Finally, note that a space is placed before dB in the unit string, since my recommendation is to display “6.02 dB” instead of smashing the units together like “6.02dB”.

(Don Turnock) #231

Perfect timing, was just working on that. Thanks


What’s the deal with component.hpp? Has it become compenonentlibrary.hpp? The template plugin doesn’t build right now because of this.


I noticed a commit comment that multiple inheritance and virtual inheritance were removed. How does this affect the compononent / ui widget library? Just the other day I made a choice button that controllers a parameter. It seemed like I needed to derive from choiceButton and paramWidget (or else duplicate a lot of code). What’s the new strategy for doing this kind of thing?


(oh, yes, I see, we are back to componentlibrary.hpp. ok, that’s fine. sorry for the spam).