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 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.
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.
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…
If it gets you down conforming to other people’s preferences, you can always change back!
But good luck with the home stretch, those final bits are always the hardest hardest, because all the fun stuff has been done. I have so many tracks that I really like which never got that last 1-5 percent of work that would have let me be really proud of them.
But the modules look really great, I hope you finish!
You are one of the most consistently helpful folks in the community, Dave. I’m sure that if you asked, there would be plenty of people willing to put their time & talents into some demo patches or videos for these cool modules.
@LarsBjerregaard - I am not down at all about switching to Ivory as the default - I am perfectly happy with that decision, it just took me a while to get there.
@demcanulty nailed my feelings perfectly - the home stretch looks daunting, and energy levels are flagging. This will be released, it is just a question of how many of those last tasks I mentioned will get done. The demos and examples could always be added later, but I think they will not have as much impact as if it all gets released at once.
@augment - I have been thinking of reaching out to see if certain folk would like to create demo videos. I think you pushed me over the edge to actually do the right thing and reach out.
If anyone has some interesting patches featuring these modules - I would love to see them. It would be great to see how people might use them when they are released. And if it really focuses on the module and demonstrates a good use case, I will likely include a link in the documentation.
I just realized I need to change how Bernoulli Switch polyphony works. Currently every channel on polyphonic inputs always get their own coin flip, so polyphonic inputs get “mangled”. I think this is an important feature, but I also need to support the simpler case where all the channels remain together, so there would only be one coin flip for the whole.
I can’t wait to try out your modules Dave. The 2 input 2 output Bernoulli switch in particular is something I’ve needed for a while now. But really looking forward to the others as well. Great work.
Thanks! Yes, I have been dreaming about this one for a long time as well.
I think it would also work especially well in hardware, though maybe expanded in size a bit to make it easier to manipulate. The more I explore it, the more uses I find - it is incredibly versatile and I think perfect for a fixed rack. But among its many uses, it also solves some niche use cases that are not covered by any one existing VCV rack module.
Ivory is now the default theme. But the main reason for a new beta version is the significant change in how Bernoulli Switch handles polyphony. The old version always scrambled polyphonic inputs with a coin toss for each input channel. But now polyphonic inputs can be left in tact with a single coin toss. From the updated documentation:
