Alternate panels

In the interests of transparency, I’m notifying here that I have closed a thread about alternate panels for VCV. I don’t want to stifle discussion, so feel free to post more on this topic below, but I would encourage users to remind themselves of the Community guidelines located at VCV - Community Rules


I have a little bit of trouble feeling free genuinely. I stifle the discussion. However, I apologize for violating something.

Hi Dr4am,

Thanks for the apology, I appreciate it.

So, my only surprise in all this is that:

  1. There is a feature to have alternate/dark panels for modules built into the Rack engine
  2. VCV Core+Fundamental serves as a great example for other module creators
  3. VCV Core+Fundamental does not include alternate/dark panels to showcase the Rack API

There are several vendors that provide these dark panels and often they look wonderful! Really not sure why there should be such a big fuss about this.

Side discussion, maybe:

In modular world it is very common for people to make diy versions, with all kinds of mixed material panels, knobs etc. It’s often really cool to see someones self-built system (I have some diy and alternate-kit/pcb/panel in my physical eurorack system as well).

It would be neat to be able to “style” your entire Rack to look like it was diy-ed together. Mixed batch of panel, hardware, knobs, sockets etc. Some pieces of protoboard and wires sticking out. Some ducttape keeping the busboard in place, etc.

I’d really like to see such a beat-up “hacky” look of Rack on my desktop some time. Would spark a different kind of inspiration perhaps :wink:


I’m not aware that there is.

1 Like

Ok I massively overstated this, sorry.

The API allows to override the menu and add an option to switch panels. Some vendors like the well known GitHub - MarcBoule/Geodesics: A Modular Collection for VCV Rack by Pyer and Marc Boulé provide this.

There is not a unified method for this though, everybody rolls their own implementation. So this is not something that you can easily add with a global toggle or something.

We’d need to connect with all vendors that provide alternate panels and coordinate the extended API for this. Not impossible of course, but potentially quite some effort to do.

Anyone care to make an overview of vendors that provide this feature? Then we could start to collect some real-world data on this :slight_smile:

1 Like

That is the way it’s done in Geodesics (two panels that get switched), but with the goal of advancing the discussion, I’d like to share a bit more about how it’s done in Impromptu Modular, which is now a bit different. Starting in v2 Impromptu, I now decided to not manage separate SVGs for light and dark panels, since making a change in one always meant keeping the other SVG updated, which can be a pain for some who prefer not to manage this redundancy. So I decided to remove the background rectangle in the panel’s SVG and have that added in nanovg code at run time and drawn below the SVG which now only has the labels. Here’s what my SVGs look like now:

All the white there is actually the background of Inkscape and is transparent. So since the background is now drawn in code, users can now alter its “color” at run time. I say “color” since I only use grayscale, so the “contrast” slider in my modules just scales the level of gray of the background (but it could technically be be color too).

Where I want to get at, is that with this, we now need to invert this SVG for the dark panel, in order to make all those markings render in a light shade and thus be seen on the dark panel. So I made an inverter widget that does this. The drawing stack now looks like this:

  1. background rectangle (nanovg code)
  2. markings (SVG image)
  3. inverter widget (nanovg code, only active in dark mode)

So to reacp: SVGs have only the markings for the light panel, i.e. dark markings that assume a light background drawn in code. Then, when dark mode is wanted, the inverter widget activates and we now have light markings on a dark background. But this trick only works when the colour scheme is invertible; with non-grayscale colours it can obviously not apply generally to everyone.

I think this technique could be applied to the VCV Fundamental modules to give them a dark mode without causing extra work for Andrew and Pyer, and I would even volunteer to do a PR for this if ever Andrew is interested in it.


By coincidence, I was looking into this just yesterday - which vendors have Light/Dark panels and how does the user choose between them?

My Sequencer and Drum plugins have Light and Dark themes, but currently no way to set the default. Ewen raised Save selected theme · Issue #86 · EntrianAudio/Rack · GitHub to request a way to set the default theme, and I had a look at how other modules do this.

Bogaudio stands out as having the best implementation - easy to understand but powerful enough to do everything you’d want:

  • A module instance can be set to particular theme, or “Default”.
  • You can set the default theme explicitly on the menu:


That means:

  • You can directly control the default.
  • You can explicitly set some module instances to non-default themes without changing the default.
  • When you change the default theme, existing module instances that are set to Default will change.
  • If a future Rack version offers a global option like “Prefer dark themes”, that will fit nicely.

(Credit to Matt Demanett and Marc Boulé for this system!)


Submarine uses no SVGs at all. It’s all done with nanovg.

Three colour schemes are hard-coded in the plugin and a context menu switches between them.


In the mean time, a kind person might code a small utility that reads a (bunch of) svg files in a given directory and does the following:

  • saves a backup copy of the original files

  • simply inverts all found color codes; i.e. after this anything with “mainly bright” colors will be “mainly dark” - but of course an inverted, negative, version at that, a bit crude, but a start in any case

  • further experiments can be done with “invert brightness but not hue” and so on

  • the utility might or might not give some more control to the user, as command line parameters or runtime prompts

An utility like this wouldn’t target any specific module or svg file - or even VCV at that - and a user could simply choose using something like this to quickly darken a bunch of panel graphics included in VCV, for their own personal copy of the software, if they so like, without distributing the result anywhere.

My own main experience is in C# / .NET :stuck_out_tongue: which I’m also using professionally, but I think distributing a little utility like this as a dotnet project is a bit unwieldy, even if a console app. Sounds like a nice and compact-scope project for a small command line utility in any case?

1 Like

Oh man, you posted this about the inverter widget fifteen minutes ago, I read your post only after writing the above :grin: … Indeed, this is a good direction. And something that can batch process a bunch in one go.

1 Like

Interesting, there is a slight difference in techniques here that is worth pointing out. In your proposal, there is a seach through the actual SVG’s code to change the colors (for example, as stored in memory after the file is read with nanosvg); my method it actually changes the rendering operation itself at the framebuffer level (nanovg). My method is less flexible than yours, but it’s perhaps simpler to implement. I think Aria Salvatrice has done your version of the inversion though, if memory serves me correctly.

Hi Marc,

I’m in the process of exploring how to offer a dark theme panel for PurrSoftware Meander. Meander has a logo only SVG (pretty much) and all other colors are determined at runtime via nanovg. I was considering doing some type of runtime inversion. But, since you have already done that, would your technique be usable by others. I see where you call the inverter in your GPLV3 modules, but I have not found where the inverter code actually resides.

If your code is not available for other GPLV3 projects, that’s fine; I will continue to work on rolling my own. But I thought I would ask as others might be interested this.

Thanks, Ken

1 Like

I’m afraid my intended proposal was less elegant than anything actively done at runtime :blush:, I meant the tool would invert the actual color codes in the svg files (backing up the originals and writing new color values into the svgs themselves). To my understanding this would be enough to make the VCV-included panels dark yet still legible, but I might be overlooking some runtime-generated graphics in them, too, that I didn’t think of?

Hi Ken,

Here’s the inverter widget, and anyone is free to use it since it’s GPLv3+ if they follow the licensing clauses as expected. This is the header only, the related .cpp file has the rest of the code.




Ah true, you did express corretly that your idea modifies the SVGs stored on disk, but I actually think it might work better if it’s changed in the data-structure of the SVG in the actual code, when those are loaded from disk and into VCV Rack. (I actually tried this method before doing my inverter widget). But there are many ways to do things, and yours would involve no code to run once the conversion is done and might be more efficient.

1 Like

This sounds very potential in VCV’s case, yeah.

Simple color replacement, only into the svg files themselves, is naturally more trivial to do, heh, and works with any svg-contained color codes, i.e. the utility wouldn’t be targeted squarely at VCV. And 100% subjectively aesthetically blabla :slight_smile: I kind of like the idea of not having any runtime “hacks” present for something like this, hehe, yep. But this is just personal preference. The actual end result is likely better and works with more modules via the active method :+1:

It wouldn’t work with svg’s in general. But I think it would work fine with the subset of svg which is actually supported by rack.

I’m thinking for example that svg supports blend modes and filters which would potentially also need to be inverted.

1 Like

While I haven’t implemented an alternate Light panel for the Volume 1 plugin (it’s something I’ve contemplated but I haven’t received any requests for it), in Rack v1 I did offer an alternate panel option in the form of “glowing panel ink” which would remain visible when the room lights were dimmed:

I wound up removing the option while porting to Rack 2, for a couple reasons. For one, I’m still not sure how I feel about the look, though I never sought any particular feedback about it. It had always been disabled-by-default. But also it was partly out of laziness; dropping it gave me one less thing to work on during the Rack 2 transition.

I’d consider bringing it back if it were requested, but also I would feel better about it if I weren’t the only developer that was doing it. I’m curious what others think. Any fans? Is anyone strongly opposed to the option?

1 Like

I think it looks cool when tastefully done like that!

The only way to “misuse” it (in my opinion) would be… forcing a panel to look mostly bright / lit even when the lights are dimmed :slight_smile:

1 Like