I think this is a nice idea in general and @marc_boule’s thoughts are great in particular. I (like several others on this thread) use different panels for multiple instances of the same module in the same patch so I’d prefer a manual override to be the expected behavior, although I will candidly admit that I’m probably in the minority here.
Per @StochasticTelegraph’s point about other themes (and similar points above), I wonder if the right open-ended design (and allocation of responsibility) would be to add an optional array to the manifest (call it something like .modules[].themes) and then use that to dynamically populate a re-orderable menu widget in the View menu based on the modules that are loaded. Modules with multiple panel types then get to say what those types are in the manifest, and they can check the selected settings as they like. (So if, say, the Doepfer A-110-4 ever gets ported, it would register its blue livery separate from “light” or “dark”, but only users who were loading that module would see the blue option in the preference stack).
These would ideally to be homogenized on import (even more than tags, we wouldn’t want synonyms).
I’ve finished the implementation of SVG theming using a JSON style sheet, with full documentation and a complete, working, well-commented Demo module.
All theming code is in two header files at the root of the repo. The two headers have everything you need. One header depends only on nanosvg and jansson for json, the other is specific to VCV Rack and dependent on a Rack build environment. Each is in single-header-file packaging. All theme support is completely independent of the Demo.
The demo is a Blank module with Light and Dark themes, on single SVGs (one for the panel, and one for screws). It shows both panel theming and widget theming. If you implement the (very simple) theming interface for all your widgets, including your panel, you can update your complete UI with a new theme from the menu in only a couple of lines of code.
The theme menu is provided by one of the helper functions in svt_rack.hpp. The other helper in that header traverses your widget tree to update the theme for every widget implementing the interface, and if any modifications occur, the DirtyEvent is sent down so that everyone refreshes.
If/when Andrew rolls out updates to rack related to theming, I’ll see what I can do to integrate it into this scheme. Should be able to get the choices for per-module theme, or follow Rack theme pretty easily.
I’m hoping for a notification event rather than polling Rack global config in step(), for something that will change very rarely.
A user suggested to VCV Support that rack rails (and the threaded nut strip) should be dark when “View > Prefer dark panels” is enabled. The rack background would still be controlled by “View > Theme”.
Eurorack users love making all-dark racks, but rails aren’t visible in full racks. In VCV Rack, they’re always visible due to the infinite rack size, so the color of rails is more important.
Intellijel, among other companies, makes black racks (although their threaded nut strips are still silver).
Do VCV Rack users like this idea? Is this proposed setting organized properly? Or should rack rails be controlled by the UI theme, or should they always be silver?
Many people’s cases have empty slots in them and many people don’t bother with blanks on vertical cases where there is little danger of a cable falling into the power. I’m very used to staring at silver rails in both Euro and Rack so giving the option to change colour is not very high on my priority list, but each to their own.
Personally, I would leave the default as it stands, whatever the theme, as about 99% of cases in the wild will have silver rails, and offer the ability to change the rail colour for those who care about such things.
I bet the black enamel/paint scratches off the real ones. Rack rashed rails.
Dark rails in Dark for me. Great photo to illustrate the idea.
Not sure how they do it, but many videos of VCV rack show the modules basically floating, without case or rails, so it’s clearly a look that many people want to see.
Personally, I run a slightly hacked Rack to remove the back plane details to reduce the amount of non-functional visual noise. I like a clean visual, but I appreciate people want as much of hardware-ness as they can get.
For them we may want to add dangling connecter wires, stray solder drops, dust, and scratches that increase under an “age” slider. (half joking).
i definitely prefer the nut strips to be very dark, and the power rails to be invisible (because it’s just a visual distraction without any function in vcv). i’d also want the background panel to be of a user definable color, so it can easily be removed by color key (in e.g. obs studio).
Shameless plug, you can both hide all the background and remove/replace anything in OBS using my VCV Library - DanT Chromakey module, this is exactly why I created it:
As a user I wouldn’t mind the ability to select a custom SVG as the rack background, I think that would cover all scenarios, Rack could even provide two defaults, one light and one dark, that will cover standard users, and power users can create or source their own custom background.
This is not a criticism at all, I love that Rack is being enhanced and getting new features, polishing the UI will make it seem more pro and should attract a larger user base. However, the background graphic is not high up on my feature wishlist for Rack, especially since there are already solutions for these issues. I would much prefer to hear about any other non UI proposals for Rack, thats what I would get excited for, both as a user and a developer
there are pros and cons to most solutions just trying to be helpful, my module will still be available to use for greenscreen effects with or without any features that Rack gets to modify the background
Easy enough to do, although it would be nice to have the feature so you don’t have to “hack” rack like the following, which some people won’t be comfortable doing.
Close Rack, if running.
Rename /res/ComponentLibrary/Rail.svg as Rail-save.svg (or something) so you can get back to the default
Run rack for green-screening in your video capture setup.
When done, rename Rail.svg as Rail-GreenScreen.svg for the next time, and rename Rail-save.svg back to Rail.svg.
You can also achieve the same thing by copying and pasting the files from a comfortable location, or writing a script to do the same. Best to save your Green-Screen svg somewhere so that you don’t lose it when updating rack (I haven’t checked that this is actually necessary, but best to back up your work anyway.)
I couldn’t agree more…
just trying to be helpful, my module will still be available to use for greenscreen effects with or without any features that Rack gets to modify the background