As someone who currently has exactly 3227 modules installed, I heartily welcome this change.
1 Like
I now feel inadequate with my 1501… of which 1401 I probably have yet to give any attention to because they came as a package.
1 Like
Not to mention that there are “only” 3142 modules currently in the whole library, free and premium combined, and the remaining 85 are painstakingly manually ported / built / etc. 
But seriously, I use this in my work and like to have absolutely everything at my disposal. No right or wrong way to go about this. It’s nice that having it all installed doesn’t have a negative effect on stability or such, though.
Ah, also: +1 from me to all the requests for more convenient categorization, tagging, folders, and whatnot. Heh.
That’s essentially what there is right now that has caused so many problems.
The issue with ‘subscribing to just this module’ is that it creates a whitelist for that plugin. So when the developer either releases a beta module for download on GitHub, or even just a new module in the library, any user that has subscribed to individual modules won’t see it.
If we added together all the hours of problems that this had caused for both users and developers it runs into hundreds at least.
3 Likes
Its not what it currently is. You only have immediate access to subscribe to module and have to dig a bit for plugins.
Also the verbage is only “add” and is not clear if thats the module or the plugin. I could see that new hsers might not know there were two things add could mean…
as someone who uses vcv almost daily, i just keep up with whats coming out so that is admittedly a difference between my use case and beginners.
But i still think this might quell the confusion peice.
I understand this works for you but Steve and I are both at the end of the support line for some big packages and I want to re-emphasize that the add a module with the current white list semantics causes the majority of our support burden (excluding of course the support burden of bugs we write in our own software 
)
It’s so onerous that I added code to BaconPlugs to make sure I never do have a white list and was thinking of adding it as a warning in the right mouse menu for the next surge xt! (But obviously would not if Andrew adds this feature)
Basically: I agree that the ability to see a subset of the modules in the browser is a good feature. Doing it with the current server side subscription ui though, especially with its reflection in a white list when modules get added, is one which causes problems for us as multi module popular package maintainers.
There’s many solutions to this of course but hope this helps you see why some of us reacted super positively
7 Likes
+1, having only collections would be a simpler and cleaner system.
agreed. This feature was a noble experiment, but it’s worse now.
1 Like
Gotcha. That admittedly is a piece I don’t interact with as a non-dev.
then i will definitely be using a hide function. Bonus if we can do this in bulk somehow (maybe hide plugins, then unhide modules…)
1 Like
I’ve never used the Add Module feature so I won’t miss it. The argument made by collection maintainers above should carry the day, in my opinion.
2 Likes
I feel that with the 3000+ module assortment a favorites “collection folder” feature would be a big benefit to include in a future update. When you want to do a VCV techno project for instance you could just open your “Techno project 1” favorites collection folder and access the individually categorized “Techno project 1” modules. Additionally a template file saving option would be a big bonus for VCV.
2 Likes
Like: File / Save as template?
Oh I overlooked that feature because I traditionally use PatchStorage.com to collect patches and they never posted templates since I signed up. I’m still slowly getting into designing in VCV with around 10 patches designed so far. If anyone thinks collection folders are a plus they should respond. I think a favorites collection is a good alternative to Dave’s idea of open patch tagging.
A better patch browsing system with a preview of each patch in an image including template browsing with preview image would be a sweet addition to VCV if category folders are considered too much clutter. It would be nice to see a visual preview of your patch when a patch/template patch file is highlighted. I was hoping I could get Vortico’s attention. The new feature idea is fine and all.
I very much echo what Steve said above and I think it would be great to remove the add-module feature from the library.
With regard to module management I’m also very much in favor of what you propose, and I think it’s best done in the Rack module browser. So each module (in the browser view) has a Favorite selection possible on right-click and a “Hide” selection is added to hide a module from the browser, possibly with an associated keyboard shortcut for speed and convenience. A “Show hidden” button/checkmark is added to the top of the browser if the user wants to bring modules back from hiding. And it would be wonderful if the Favorite and Hidden modules are synced to the users VCV account, that would be a very useful service!
4 Likes
At this point I might also mention the possibility of toggling module image rendering in the module browser. When you know what modules you need, there’s no need to render everything as images every time. Simple lists of names, categories, etc, nicely formatted, would be enough. As in, let the user toggle module graphics in the browser on/off.
2 Likes
As a developer I agree with this change, but I think it would be helpful to users to have a hide option in the module browser
3 Likes
Thank you for inviting feedback. I hope I have not misunderstood the proposal terribly.
It seems that it will be impossible to add individual modules to VCV rack anymore, and one will have to add the entire collection?
I am perhaps in a minority but I have only ever added single modules, and I have spent a lot of time trying out and testing to try and trim it down to a quantity in the browser which is not totally overwhelming for me!
For some context I just had a look in my browser, and I have 11 envelope generators to choose from when I am building a patch, more than enough to cover every use case and to experiment and become familiar with. I have chosen this limited selection in the hope of getting to know them better, and it’s possibly already too many to do that effectively!
I have modules from 79 different developers, and among them are the following with envelope generators in their collections…
ALM Busy Circuits 1, AS 1, Audible Instruments 1, Befaco 2, Bogaudio 8, Chowdsp 1, docB 1, Instruo 2, Little Utils 1, MindMeld 1, Mockba Modular 1, NullPath 1, NYSTHI 13, Ohmer Modules 2, Sickozell 4, Submarine 1, Surge XT 2, VCV 1, Voxglitch 1, Vult 4, XTRTN 1. Total EGs = 50
If it’s the case that I would see, by virtue of being subscribed to these devs entire collections, five times as many EGs in the browser, many of which i have previously tried and decided i didn’t need or like for some reason, then while the change is intended to deliver other benefits which I duly recognise, I struggle to see this as an improvement to my own personal user experience. I would honestly find the excess of choice overwhelming and it would seem that all my hard work in curating modules had been undone.
Accepting that this change will happen, I would like to add my voice to the people asking for hiding of modules in browser, to me that’s an acceptable solution to the in-browser side-effects of removing ability to add individual modules.
In fact I would go a little further and beg you to include such a mechanism at the same time as the proposed change is implemented, rather than making us wait for a later update. I would find the browser very difficult to use in the meantime.
Thanks for your consideration.
4 Likes
Adding a vote to syncing favorites and hidden modules with VCV account. This solution would work for all users it seems.
2 Likes
Given that there are probably many users who feel they have put in significant time curating what individual modules they see in VCV (and this doesn’t include me, as I have pretty much everything installed, but I’m seeing the issue from your viewpoint here), I think the most graceful way for this change to work - so that a part of the userbase doesn’t feel let down - is to include the module hiding functionality at the same time this change is being made.
In other words, please consider this from those users’ viewpoint, and instead of “in a later VCV Rack update, we might add module hiding”, consider adding module hiding when making this change, and automatically hiding those modules which aren’t currently added to the user’s module selection, yet included in the plugins the user currently already has selected some modules from.
8 Likes