I mean, that seems like it would work just fine, but surely it is far quicker and easier to just add a few Chromakey modules to the patch instead?
Unfortunately I don’t have much spare time to work on my plugin at the moment, BUT, I am wondering if I could build some sort of feature for the Chromagica module that could automatically insert a bunch of Chromakey modules to “surround” a patch…
Great idea – my upcoming Null blank module is one minor feature away from being perfect for this use case. it already has removable screws. I just need to add another menu option to remove the title and logo, so that it can be made 100% blank. I can add a preset for Chromakey usage, so it’s a single gesture to use it for this case.
What’s the perfect color for Chromakey? Or what small number of choices are best? Just let me know and I’ll include presets for the required colors.
[ed.] Tracking issue: Null: Add option to remove all chrome for completely blank panel for Chromakey usage. · Issue #9 · Paul-Dempsey/pachde1 (github.com)
Modules can expand beyond their bounds (the Computerscare blank picture module is able to do this), so another implementation approach is to size to the entire window, then leave un-drawn holes for each module in the patch. Then you only need one module to accomplish the scenario.
It really depends on what else is in the frame. You want a colour that is either not already present, or one that is used the least, because you are going to remove that colour, how closely you match that colour determines how much of the image you remove.
With most “real world” footage, you won’t often find “pure” colours so these tend to be the best options: Red, Green, Blue, Cyan, Yellow, Magenta
But you can really use any colour you want for Chromakey, I have included the basic colours as presets for convenience, but my Chromakey module just allows anything and everything, you can set it to any colour, you can have it full brightness, or use the room brightness, you can lock in a colour, or you can control the colour dynamically via the Chromagica module.
I suppose that could work, but it would have to dynamically change either the panel bounds, or where it cuts out the holes (or maybe both, haven’t thought about it enough) according to the camera.
Doing that as a user scrolls around a large patch, and zooms in and out sounds like a bit of a nightmare tbh.
I was thinking more along the lines of looking up the modules positions in the patch.json and simply adding new ones either side, on top and bottom of the ones with the highest and lowest coordinates
I have parallel features in my upcoming pachde-One plugin. Null for blanking (just needs an option to completely strip the branding). It is already has the light option, and colors from hex, palette (my colors menu has the primaries, a gray ramp, and all svg named colors), or extender (the modulate-able Copper color-picker module).
It would be nice to figure out a common extender color-interchange protocol so we can interoperate. it could be as simple as dynamic_cast a rack::engine::Module::Expander to:
struct IProvideColor {
NVGcolor color();
};
I don’t know if this works with independent definitions of this struct, or if a shared header needs to be published. I haven’t coded that experiment yet.
One of our members extensively uses something along these lines in their stunning videos. I wonder what their thoughts (and techniques) are.
This has gone off on a slight (but very interesting) tangent to @Vortico’s original question, which chiefly concerned what the default should be.
[I indicated silver, because of the phrasing of the question which referred to physical cases, but really I don’t care much at all if a change will make things easier for what other people are keen to do visually.]
i personally chose a dark brown, as it is an uncommon color while also not being blinding as e.g. pure green. most dark modules use some shade of grey, or mix in blue.
for any module based solution to work well, it also needs to fill in any gaps between (groups of) modules automatically, otherwise it won’t be seamless and a lot more of a bother.
but really, a user-definable solid background color would be the best option.
Thanks for all the feedback on the colors – I decided on three basic familiar ones for presets: green-screen, blue-screen, and magenta-screen, if you want something else, you can type in the hex code, or use the Copper extension module for a visual color picker.
The chromeless version will be an update after the plugin is released, which is already in the queue waiting to appear in the library. It doesn’t look like the library got updated this week, so hoping for next week.
I’ve updated the Generic Blank template repository to support the new “Prefer dark panels” option in Rack 2.4.
GenericBlank: Template for a VCV Rack Blank module (github.com)
This repo is a template for a minimal, but complete VCV Rack plugin. It contains only a Blank faceplate module. This is a simpler alternative to the Rack tutorial as starting point for new plugins.
By starting with a completely working plugin not using helper.py, it avoids some of the struggles new developers may have when starting with the Rack tutorial. The repo contains documentation, and the code is extensively commented with instructions on how to take this starting point and build out a functional module.
I’ve added documentation for the “Dark panels” feature at Plugin API Guide - VCV Rack Manual.
The bool for testing DarkPanels preference has an ‘s’.
From settings.hpp:
extern bool preferDarkPanels;
Hopefully other VCV supplied plugins like Audible Instruments will also be getting the “Use dark panels if available” treatment. Maybe something like this?
Fingers crossed!
Hopefully with less contrasty knobs, they’d give me a headache.
Also, still wondering when the premium VCV modules we paid actual money for might get updated.
those look very familar! 
Émilie already said okay once to such panel variants, so should be easier a 2nd time.
while we are at it, white not white befaco too? 
