Ooh - I have been wanting something like this, assuming I understand what you are saying.
What I really would like, especially for the Rhythm Explorer square buttons that are currently SvgSwitch is a dim square backlight with opague (or translucent) text on top.
I tried placing a light before (presumably behind) the SvgSwitch widget, and making the svg background transparent. But it did not work - the svg text did not obscure the light that was behind.
The lights render on a higher layer on top of unlit things. So to place text on top as I understand youād have to make a hole in the ālightā for the text to show through. Strange but ā¦
EDIT: if you make a second copy of the button svg and fill the translucent part of the unlit button with the light colour, then like line 116 draw the 1 layer with the lit (based on state), and the 0 layer with the unlit (always), as long as you use black text, the illusion of just fading the 0 layer to black to dim the room might work.
EDIT2: Does dragging a switch scroll through the frames?
No, there is no drag operation. Each click advances the frame, and at the end it cycles back to the first frame.
A right mouse click opens a context menu to choose from the list of options.
Iām thinking knobman and iPlug or such.
??? I donāt know what that means
read more forum stuff. Itās a huge deal for some people.
Yep, I read every post.
just meant it seems to me that a lot of ppl here have said that the look of a module is important to them.
Please - enough about the philosophies of faceplate design - especially color schemes. That can go on forever and agreement will never be achieved. And philosophical discussion is not the purpose of this topic. I also have read many posts, and am aware that color and contrast are critically important to some, and a total non factor for others (as long as features can be made out of course).
I have appreciated the viewpoints expressed so far, and it has helped me get to where I am. But I think that is enough. For this first release anyway, I think I am set with the color schemes of the four themes. Iāve included both light and dark themes, as well as a low contrast version with earth, and also managed to express my individuality. I suppose if someone has a very specific visual need and corresponding recommendation, that would be OK, but I doubt I will make any more color changes for the first release.
I may switch to using Ivory for the documentation so as not to scare anyone off, but keep Danger as the default plugin theme just to satisfy my personal itch. The default can easily be changed to taste.
Thanks @Squinky for the comment about density. I do like to conserve space as much as possible, so as to be able to see as much of a patch containing many modules as possible without scrolling. But I also want things to be easily controlled without fear of accidentally changing the wrong control, or being unable to read miniscule labels, or having difficulty finding the control / port that you are looking for. I was striving for a balance, and I interpret your comment to mean I succeeded, at least for one person anyway 
I still would love to hear about any experience people have had using any of the modules.
And of course, please report any bugs. I do hate those pesky things. I try to find and fix them before anyone else discovers them. But I am certainly not perfect, and I have no prior experience with the VCV Rack API. So I could easily have missed some important fine point.
Oh shoot, the library. Where does the library image for each module come from? I imagine it is automatically generated using the default theme for the plugin. Iāll have to think about the library some more, and I might change my mind about the default theme. I realize there may be some risk if I donāt, but it might be a risk I am willing to take.
I would love to gauge how many people would really skip a plugin based simply on their first look, without checking out the functionality and if there are alternate themes or skins. But I donāt think anyone reading this can help with that because you probably wouldnāt have gotten this far if you hated the default color that much!
I feel like, at the end of the day you gotta follow your gut, and just have fun. At least you donāt have to buy a hundred panels of each color or anything like that, itās all just free bits and photons! And you can change your mind later or add new layouts.
I have had several ppl here say they never tried my modules because they didnāt like the title font. Others that said they avoid light modules if there was an alternative.
As far as I can tell yes it is automatically generated from the code, where all the controls have some default state (so for example lights are set to full brightness).
And then I believe it is cached as well, because I have certain modules that can change appearance, and these changes are not always reflected in the browser.
You probably know, and it has been mentioned before in the forum, but you can control to a certain extent, what the module looks like in the browser.
In the draw or drawLayer methods you can use:
MyModule *module = dynamic_cast<MyModule *>(this->module);
if (module)
{
// code for drawing the module in the rack
}
else
{
// code for drawing the module in the browser
}
So you could for example set your modules to always use a specific theme in the browser with a static variable (because the module does not exist, you cannot use any data from it when drawing for the browser)
And similarly, if you want the browser to reflect the users selected theme, then you would need some sort of static or global variable that you can read to indicate what theme the user has selected.
I donāt know if there is a way to invalidate the cache of the browser image on changes though, so i guess sometimes the browser will not match user selectionsā¦
The library seems to build from the insert module pictures, and sometimes does not update the pictures even when new front āplanelageā is added.
EDIT: Panelage and all things visual. is a thread I just made to combine panel stuff.
The library image is generated from the plugin. There is a command line option to VCVRack which will cause it to start, instantiate each module, render the module once and save the image as a bitmap and then VCVRack closes.
So you can use it yourself (I use it to generate the images I put in my documentation). But the library build process does it for your plugin. There is no saved json loaded into your plugin, so it will have whatever your default skin is.
you can have a bit more control over how your plugins look inside the module browser, as previously discussed.
Thank you! This works great. I had never been able to figure out how to do this.
In extreme cases colors can have a great impact on usability, and simply the desire to use it, which I think is a factor.
I think it depends on the intention of the developer/vendor: If the idea is āI want as many people as possible using thisā then a āstandardā (dark,light) theme is probably a good idea. If the idea is āIām gonna do what I think is right/fun/nice/ā¦ā then other people really donāt matter that much.
I do that in some cases. An extreme example: The mental plugin. Iām a simple person - I just want some labels, that I can read, and some colors that donāt make me blind, and a feeling that I can use this without having to read the manual every single time.
Okay, thatās a little extreme I think.
All I was trying to say is that many factors, including usability, have highly subjective components.
Agreed, mostly, although a great many usability studies have been conducted over the years, and I donāt think itās unknown territory what the broad majority of humans regard as good/bad usability, in broad strokes. In other words, itās an active field of study which does have some metrics backed, somewhat objective things to say. I think itās good to think of personal taste and usability as two distinct but related areas.
OK - Iāve finally decided to heed the voice of the vocal majority and be less pig headed, and select Ivory as the starting default theme after all. But I will keep all 4 themes available, and each user will be able to select their own personal default.
Iāve updated the documentation to be closer to the intended final released form (using Ivory of course)
The current GitHub code is labeled as version 2.0.Beta3 in plugin.json, but I probably will not build and release binaries for Beta3, and instead will go directly to the official 2.0.0 release.
Barring any last minute bugs or usability issues, the only thing remaining is to document some use cases and/or include some demo patches and/or prepare some demo videos. I have to admit I am losing steamā¦