Hiding modules: working proof of concept (v0.6.2) [now with GIF]

Hi all!

New to the community but have been using this fantastic software for a little while (only v0.6.2 so far). Forgive me if this is better off on the Issue Tracker but this seems like a gentler place to start.

Since I started working with more plugins I’ve been wanting a way to hide models (I haven’t seen this mentioned that often but it’s the exact feature requested by https://github.com/VCVRack/Rack/issues/1219).

I just implemented one against v0.6.2 (this post was originally a “should I” post but that’s moot now). As shown in the GIF below, it works like this:

  • Opening the Module Browser with CTRL held shows all models but replaces the favorite button with a Hide button.
  • If any models are hidden, they’re not loaded into the Module Browser when it’s normally opened.
  • Projects with hidden modules will still load normally; this only affects the Module Browser.
  • Hiding takes priority over Favorites; if a favorite is hidden, it doesn’t appear, but once it’s unhidden it’s back in the Favorites area.

It ended up being cleaner to just add the list of hidden modules to settings.json (next to the favorites list).

I’m using this now and really enjoying it–is anyone interested in a fork? (I can do a pull request if that’s appropriate, although I know v0.6.2 is the end of the line and that the ModuleBrowser is changing in v1.0).



A couple of module developers have asked for this, mostly to hide modules that are deprecated but kept around so as to not break old patches.

Seems like a neat idea, although I’d rather have a window where you could pick which modules were shown or hidden (ex. I really only want one or two ADSR, not ten mostly identical ones.)


Thanks, @Skrylar. I’ll count you +1 on both the idea and the GUI version, then.

[EDIT: I went ahead and wrote a GUI version; see the edited original post].

Hello, new to VCV and first post.
Was looking here for a hint of such a feature, so I’d be very interested.

1 Like

Also very interested.

1 Like

Hi all–

Thanks to those who have expressed interest!

I’ve been following the discussion on Rack V1 and licensing; it’s provided some useful context on @Vortico’s totally reasonable opinion about pull requests/code contributions (that they’re an order of magnitude less efficient to manage than in-house implementation, and that they may well require copyright reassignment after V1).

This is also a strange time to be discussing forks and features, with Rack V1’s release apparently only weeks away (at most).

So here’s what I’m planning to do:

  • By Monday, I’ll release a fork of v0.6.2c that has my simple implementation of hideable modules in it, in case anyone wants to try it out (or use it while they’re still in v0.6.2). It’s not elegant code but it seems to work fine.
  • As soon as V1 is out, I’ll implement a version of it in V1 (for my own use) and create a feature request that includes UI and implementation suggestions and an animated demo of it working in the V1 browser. (I’ll try to get https://github.com/VCVRack/Rack/issues/1219 absorbed into this request).
  • If the FR is approved in some form, I’ll wait for an official implementation. If it’s denied, but there’s community interest, I’ll consider releasing a fork for anyone who wants to patch it in (and of course I’ll make the copyright for that fork assignable to the official release).

I think that some version of module hiding is going to be important as Rack grows, especially in the V1 browser, where modules (and therefore unwanted modules) will get significantly larger portions of the screen then they do now.


1 Like

If there is something to test on Mac 062c, please call me :grinning:

:slight_smile: I’m not going to be able to do any real support for the 0.6.2c fork but it should work on Mac and Linux, since it sticks as close to the implementation of Favorites as possible.

I’ll be curious to see if there are any issues, and I’ll be very happy if you like using it!

To save you the time of making a feature request to VCV Rack, here’s why I don’t need it.

Later this year I plan to release “plugins.vcvrack.com” which will replace https://vcvrack.com/plugins.html. You will be able to view individual modules per-page which will be generated from the metadata in plugin.json for each plugin. An “Add plugin” or “Add Plugin to Cart” button will be on the page, which will add the module’s plugin to your account.

What will likely happen in a later update (maybe next year) is that two buttons for free plugins will be available: “Add module” and “Add all modules in plugin”. If either button is pressed, the next time Rack checks for updates, it will sync all plugins to your Rack installation, but it will hide access to modules not selected in a plugin (unless you add all modules).

In other words, if the above paragraph is accepted, it will require a restructure of the VCV account database, new API endpoints, and of course changes to Rack’s HTTP API client and C++ API.


I’m really glad this is on the official horizon. I think that hiding modules is going to be a necessary feature for many users, especially if Rack grows as much as I suspect it will. Separately, I think the per-module view on the website will be nice, and it makes sense to link the two.

I wonder, though, if there’s not still a good reason to have the hide functionality available locally (i.e. in the Module Browser) as well. Having used the implementation shown in the GIF for over a week I can say that there’s a really nice flow (at least for me) around testing and hiding modules that having to cycle through the website for everything would definitely disrupt.

Moreover, making the website the only official, non-JSON-hacky way to hide modules would be more frustrating during offline use. That’s rare for general users, but there are plenty of pro audio people who don’t have their studio DAW online unless necessary, and who are often used to very customizable software. Having to go online just to hide redundant modules from a new plugin would add some friction from the get-go.

So the feature request is really “implement a way of hiding modules from the ModuleBrowser,” which isn’t redundant with the VCV account integration you describe, and would actually pave the way for it. As I’m sure you (@Vortico) appreciate, the “hide access to modules” functionality is a trivial modification to the browser (as long as hiding a module would still allow patches with that module to open normally if the hidden module’s plugin was installed, which I think would be the universally preferred behavior). Linking that to the VCV account database, as you suggest, is non-trivial and will take some time. But the “hide module” verb in the Rack client would be the same.

I’m going to re-implement this in V1 immediately for my own use, and I’ll have time to write it up and record a demo. Would you actively prefer that I not write a FR for local hiding after V1 leaves beta?

The plan is for settings.json to have a "enabledModules" property, where you might find enabledModules.MyPlugin = ["MyModule"]. Upon syncing with the VCV API, the list will be overwritten. If some plugin MyPlugin2 is not in the list, all modules in the plugin will be implicitly enabled.

Sure. In my test implementation I did it as a blacklist, not a whitelist, which means that there’s no implicit special case and that the relevant property starts small and grows large, but that’s just a detail–the two are obviously equivalent at the end of the day.

The question is: why not allow the ModuleBrowser to write to, as well as read from, settings.json:enabledModules (as it currently does to settings.json:moduleBrowser.Favorites) from a thoughtfully designed UI and then sync bidirectionally with the VCV account using the API?

This has the additional temporary benefit of allowing useful module hiding before the account API endpoints have been implemented, the database changed, etc.

Same answer to the question “Why won’t the entire Plugin Manager be implemented in Rack?” Simple, because web apps are 10x easier to build than C++.

1 Like

Then web apps must be very easy to write indeed :slight_smile: because doing this locally is really, really simple.

I’m not speaking theoretically here. Below is a diff on an inelegant version that seems to work fine (at least for me on Windows).

Most of the new SLOCs are just duplications of the Favorites routines, as in SeparatorItem.setModel, appModuleBrowser[To/From]Json, and the button definitions and onAction method; those could easily be factored/DRYed out. 602-3 is the entry point to the new code path. The only lines that are interesting at all are in 344, 396-398, 402-410, and 463.

There are obvious design questions, like:

  • should the “hide mode” browser look different (other than ★ being replaced by H)?
  • is holding mod when opening the right way to go?
  • should hide mode also have favorites buttons? (I tried this but thought it was too confusing).

I’ll rebuild-test and doc this tomorrow. Please do take a brief look before you dismiss this out of hand, though. And @jue, @Dellen, @Skrylar, let me know if it works for you? It should build if you follow the official instructions exactly.

But you understand why this shouldn’t be done locally in VCV’s version of Rack when the user can do it in a web app, right?
Your fork is fine, I just want to make sure you understand why I’m rejecting the feature request.

I don’t understand why you think it shouldn’t–the only argument I’ve heard is ease of implementation of the web version, although I may be missing something (been a long day!)

I do understand why I think it should be available in both places. Put simply: would you want Favorites to be available only in the web app?

I don’t think so, and, again, the reason is flow. After I test a module and find it redundant, I want to hide it immediately, not after I open a web browser, re-find the plugin, and re-find the module.

A less important reason is supporting offline hiding, mainly relevant to mostly-offline users [= pros], who will be happy to go online to download a plugin but probably not to customize their software.

A fringe benefit is that this could be available to users with 3-5 hours of work, rather than 50-100 to update the account DB, endpoints, etc., and that implementing it would actually implement the “hide” verb that the web version would need anyway.

I just got the “consider other people’s opinions” notification from Discourse and maybe that’s a good point. I’m glad you’re OK with the fork. People should feel free to try it out in v0.6.2c (I’ll offer a week of light support in case there’s a big bug or cross-platform issue) and I’ll re-implement it for V1 (local only) in another fork. I won’t do a formal FR since you’ve rejected it informally, but if enough people–or even you, if you try it–like the local option, you’re free to reconsider and do your own more elegant implementation.

I wasn’t really interested in an argument. There are thousands of other tasks I need to be working on this year.

Hey, I definitely wasn’t trying to have an argument either (or tell you how to manage your time and priorities). Sorry I bristled at “But you understand why… right?”; I didn’t, and still don’t, but you have no obligation to explain.

I’m looking very forward to the fruits of those thousand tasks, and I wish you the best of luck with them. You’ve found a chance to do something very significant with this software, and I’m glad you’re taking it.

1 Like

@jue, @Dellen, @Skrylar : basic documentation added to the repo (link above). As I mentioned, I’m going to keep this open for a week, so if you have a chance to test it and let me know what you think, go for it!

I think we should probably end this thread here, as this shouldn’t become a fork dev forum. I’d request that you either PM me here or reach me on Github with followup.

Many thanks.

Agreement level over 9000