I agree, the growing consensus seems to be that the proposed library change is good but that users who have been carefully using the add-module functionality to curate their library will be unhappy with waking up one day and finding that they suddenly have a load of modules they didn’t want.
Not only would it be good to have the ‘hide’ functionality available at the same time as the underlying library change, it would be still better if currently grey-listed modules (i.e., those which haven’t been added) were automatically hidden from the outset. I otherwise foresee a lot of confused and unhappy users.
I set the browser to “Most Used” so all of my favourite modules are there as soon as the browser opens. I rarely have to scroll more than a page or so to find what I need (I do run Rack full screen on a large 4K monitor though). I’ve never added modules individually, don’t really see the point as the whole plugin still gets downloaded regardless, it just adds further needless complexity which is clearly confusing for many new users.
The opposite of the white list into the hide list you mean right?
(If the existing white list was a negative black list on the rest of the non added plugins when you add the new module problem would not be there too. In a way the “add to whitelist” has the wrong “sign” when modules get added)
on my account (pro version) I always subscribe to the whole “plugin”. my pcs were good when new, now they are becoming old-ish but still run pretty well. on the other hand, at home (on my gf’s terrible pc lol) I have a free account and I have just a couple of individual modules in addition to VCV and Audible Instruments, because I use it just to develop basic ideas. I don’t see the point to remove this possibility, but if it is better to avoid confusion for some users, let’s do that, no problem
I guess I could, I might just wait until they add the auto hiding feature. Looking in my owned modules section I can see each individual module I’m subscribed to, but going through each of those is going to be very annoying.
fwiw, I think a lot of ppl would agree that this was a good feature, and was asked for a lot. The problems with the implementation were:
a) if was hard to find how to subscribe to the plugin, much easier to add the single module, even if that’s not what you wanted to do.
b) since the feature blocked seeing new modules, and it wasn’t clear why, many found the feature very confusing.
It’s not 100% obvious if both these problems are solvable. It certainly wouldn’t be trivial.
imao, removing the feature was better that keeping the problematic implementation.
Apparently there are two user profiles. Those who like to have a maximum of possibilities at hand, and those who carefully choose the modules they use so as not to clutter up the library.
I fall into the second category, and I have to say that I really don’t want to end up with hundreds of unwanted modules in the library.
I don’t really understand the problem with the current system, insofar as, as I understand it, when you add a module, you actually add the entire plugin. So it’s this whiteList that makes modules appear in the library or not ? Am I right ?
I’ll take your word for it when you say it’s a problem, but what would be the difference in proposing a hide function that would ultimately play the same role as this white list ?
In any case, it would be nice if the modules that were “hidden” remained so during the transition.
I find it much easier to choose what you want, rather than getting rid of everything you don’t want. Those who’ve relocated recently will understand what I’m talking about haha.
Setting the module browser sort order to most used solves this problem.
I have 2887 modules installed, I typically pick from a favourite selection of around 300 or so, with sort set to most used, I right click and there are all my favourites at the top of the browser, I may need to scroll a little to get what I want but not far, and I never see modules I never use unless I want to try something new, in which case I typically set the browser sort to random . I really don’t see how this is such a major problem for some people, do you all go through your binary folders and delete all the OS util executables you never use?
Another solution to the problem would be to change from include (white) list to exclude list which is basically the same as a hide list
Right now when you add a module you get the entire plugin and an entry which says “only show this module”. There’s two primary problems that causes for module supporters
Most people don’t want that. Having subscribe be a dominant action would help here
If you add a new module users why have added everything don’t see it. This is literally the highest frequency support question we get on a new surge release!
If instead the system maintained a hide list and new modules showed up non-hidden then you have to hide them, which is what many folks here have suggested, then those two problems disappear
It’s more of a UI problem. Hide liste or white liste, it’s a developer’s tool. If there’s a way, a preference maybe, to be able to show what you want, and not hide what you don’t want, it doesn’t matter (for me as a user) if it’s a white list or a hide list in the end.
If I want a single module from a large collection, I don’t want to have to hide dozens of modules individually.
After that, it’s a good thing that new modules can appear.
The second thing I’m more worried about is suddenly finding myself with 2000 or 3000 modules instead of the 520 I have, and having to clean them up.
Is it possible for White Lists to be converted to Hide Lists ?
Or is there a way to list the modules in my library ?
Having too many modules is something of a self-created problem. You have chosen to subscribe to a large number of plugins.
The library already supports multiselect (Ctrl+Click the ones you want to operate on), so when the future option to show/hide a module arrives, it becomes pretty efficient. Like previous posts have mentioned, a way to show text lists without the previews in the module browser (similar to the listings on the plugins page), would make the management task easier to get through.
re " is there a way to list the modules in my library ?"
It’s pretty simple to get a list your plugins and modules from the command line (a.k.a. in a terminal). For example, on Windows, I open a command prompt, cd to C:\Users(me)\OneDrive\Documents\Rack2\plugins-win-x64 . A simple dir (or ls for linux/mac in the equivalent folder) listing is the list of plugins installed. In the same location, findstr /s "name" plugin.json (or equivalent grep) will show all the modules in the respective plugins. (I realize command lines are not for everyone.)
Not really, most of them were picked up from watching tutorials. I don’t know how many I actually use, but a lot less for sure.
Ok you get the point
I try (osx terminal) but I get a “zsh: command not found: findstr”
Alternatively I can back-up all json files, and simply look inside, as needed, to see which modules were present and which weren’t.
I’ll do it now haha
On OSX you’d use grep, egrep, or something similar – whatever your system text find tool is. Also simple in most text editors (e.g. VSCode common for module devs) to do find in files.
