I am not in a position to approve or disapprove. But I don’t like the system, and I think it’s quite flawed, and sometimes even harmful.
1 Like
Just a quick personal philosophy. Use the tools (and data) you have to their fullest potential before thinking up more complex tools and data assessment methods. Don’t reject a tool because it isn’t perfect as no tool is ever perfect.
In the online Library, I see about 374 plugins. We can sort that list by NAME, CREATED and UPDATED. If VCV was to add INSTALLS, we would have an easy first step for identifying which modules have stood the test of time and rose to the top with the top plugin having 178K installs (or somewhere in that range), but the top N plugins still having a meaningful spread of installs, even for those that have been in the library for the same amount of time (say 3 years for the oldest).
Yes, these numbers are very proportional to the length of time that the module has been in the library, but, other 2nd order “hidden variables” effects are clearly visible. By and large, a beginner could hardly go wrong by exploring the top 25 plugins. And that is the objective, is it not?
Maybe the VCV launch tooltips show a “Have your tried…” tooltip occasionally which highlights one module at random from the Library?
Or, in the right click menu, there is a “See other (e.g.) VCA modules in the VCV Library…” link which takes you to the VCA category page in the VCV Library?
1 Like
Here is a cross-link to an applicable page from history for this topic.
https://community.vcvrack.com/t/barriers-to-plugin-adoption/905?u=k-chaffin
1 Like
Cross posting, sorry…
In reply to Any interesting APIs surrounding Rack/modular/music? - #14 by k-chaffin
I just checked the obvious and it actually works:
https://library.vcvrack.com/plugins?query=&sort=popularity
The plugin list sorted by most “popular” on top. And as can be seen right away, it’s definately in part a function of how long they’ve been in the library. As I can recall the “popularity” is simply number of downloads/subscriptions, so the early plugins offered from the start of the first Rack version has a huge, automatic advantage there.
So popularity sorting is already there, it’s just not surfaced via a button.
Also to note that proprietary/non-open-source plugins don’t have a popularity number, so they all fall to the bottom, which is a bit unfortunate and definately limits the applicability as it is now.
In looking at this I think the current “popularity” number is close to useless. If I were Andrew I would probably get rid of it and think of a new way. It’s probably also why it’s not surfaced via a button.
If real popularity would mean “how often a plugin or module is actually used by someone” then I’m afraid it can probably only be done with an opt-in telemetry system in Rack, kind of like the Debian “popcon” system. The only alternative is a like/vote system in the library, with it’s rightly/wrongly perceived gaming-possibility.
2 Likes
In thinking some more about this, the following is probably how I would design a like/popularity system for Rack:
- Introduce a new menu item in Rack: “Library → Opt in to popularity ratings”. It’s a boolean checkmark that is unchecked by default, because some people are paranoid about telemetry systems.
(Actually, given that Rack is open source, and it is very easy for people to verify that only “local-counter-database” is uploaded, it might in this instance be easily defendable to have it opt-out instead, to give good numbers.)
-
Have the first tooltip on first Rack start be something like: “Help fellow Rack users find good plugins and modules by opting in to popularity ratings in the Library menu”, and promote turning it on, on e.g. the Rack download page.
-
If a user has opted in to participate, then every time they actively place a module in a patch, Rack updates a counter for the module and the plugin, in a little, slightly obfuscated, internal database. The user ID/token is NOT part of the counters database, and all ratings are anonymous.
-
When a user starts a new patch, the modules and plugins in the new patch, which is a result of the content of their template, are also counted.
-
A plugin and a module is only counted once per patch, no matter how many instances of it they place.
-
On a regular basis, if a user has opted in to the popularity ratings, Rack will upload the internal database with plugin and module counters to the library backend. It will then reset/delete the local counters and start counting afresh.
-
Now the library backend knows which modules and plugins are actively used by actual users.
-
It can now surface and present those numbers in a relevant way on the library web page.
-
The counters only cover a period of say one year, so that it reflects the current usage, and not artifacts of history. Of course the library page can choose to display historical graphs and data as well, if that seems like a good idea, and possibly make them available for download.
Thoughts?
2 Likes
Yeah looks good to me, that was my thinking though without the implementation steps. The only thing I definitely wanted to avoid was any use of timers as I know how resource hungry those things can be.
Having a set window like only looking at the previous 12 months is a good way to spot current usage too so doesn’t massively favour modules that have been around forever over newer ones.
2 Likes
Thinking on this more, I’d probably want it to count only the first time a module is placed in the current patch so you’d get at most one module count tick per patch because for example big mixer modules probably only appear once and envelope generators and VCAs multiple times in a patch.
3 Likes
Yeah, let’s keep it here where it belongs.
1 Like
Yes, good one. I’ve updated my design sketch above.
Yeah, let’s keep it here where it belongs.
I agree, but I am not the OP for either topic. Perhaps this topic needs to be renamed something more general, if the OP is agreeable.
I’m only arguing for keeping the discussion of like/popularity mechanisms in this thread here, to keep it on topic.
1 Like
I was thinking much the same.
Perhaps the popularity data transfer could be incorporated into the existing library update process.
I’m thinking that the count should ignore duplicates in the same patch. So it would measure the number of patches that use a given module. This might be a bit trickier to implement, but I think it would be a more useful number. (I see that main.tenant beat me to the punch)
Either way, I’m not sure how to handle removal of a module from a patch.
===============
Another possibility is to have some spider download all the patches posted to the VCV community and/or Patch Storage, and parse the files for module counts. The modules need not be stored in a database - just the URL with its module counts.
This system would certainly be biased - I imagine only a small percentage of users actually post their patches. And typically only a small percentage of a given user’s patches are posted. But it would also be a limited form of curation - presumably most users only post patches they are proud of.
One distinct advantage - it could be implemented and maintained by the community. It need not involve VCV development.
1 Like
I like these ideas in principle, but what is the likelihood of any of this being supported. Unless we submit a feature request to VCV, nothing will happen. I submitted mine yesterday and that one requires no new functionality to implement, just a change to the library plugin reporting.
That is precisely why I made my suggestion in my post above.
1 Like
As a hybrid approach, how about talking VCV into enabling the current reporting sort by “popularity”, with or without reporting the actual popularity numbers. I’m pretty sure all of that work is mostly done, since 2019.
And then work on a nuanced popularity approach that is as unbiased and objective as we can make it.
But a lot of people, including the OP, want a subjective ranking, which is certainly valid and useful, but much more susceptible to bias and noise and manipulation.
Sure, it could. I just write “regularly” to say whatever fits the available bandwidth best. It’s Andrew who’s going to implement and decide this anyway 
Yes. I’ve updated my design sketch.
Well, if a user removes it it means they placed it first, so they had an intention of usage. Also, modules only tried once or twice, and not used again, will have a very low count, so it won’t matter. In general I think it’s important to have a simple as possible implementation, without complicating things too much, and still in the long run give good, reliable numbers.
Yeah, anything is possible but I don’t think this will give good, reliable numbers, and will rely on flimsy scripts to foreign systems ect. I must say I’m not a believer
In thinking about it I’m becoming more and more convinced, that if the aim is to have good, reliable (ungamable) numbers, that people can actually use for anything, it needs to be baked into Rack. I wish it wasn’t so but I think it is. A system that doesn’t give good numbers I think is close to useles, or worse…
Yes. For myself I’ll let my design sketch above sit for a few days and people can give some feedback. If it seems to have support I’ll submit it to Andrew for consideration. I already have a good inkling of what the response will be, but always be open for pleasant surprises
Well the link above that I gave works for that. https://library.vcvrack.com/plugins?query=&sort=popularity So nobody needs to be talked into it. I think what you probably mean is ask Andrew to enable a sort button for that in the library. As I wrote above, if I’m honest I think those numbers are misleading and close to useless. I would not enable it myself. But hey, it’s Andrew’s system…
Hmm… maybe. But do they? My design sketch above is a design for an objective rating system rather than a subjective one. Let’s see what people think. My gut feeling is that in the end most people would prefer an objective rating system over a subjective one. But hey, no such system can ever be perfect, but it just needs to be the best one we can come up with, and then it’s up to Andrew if he want’s to implement one anyway, which is far from certain.
1 Like
As a developer, this number is kinda nice to know - but it should be called what it is: “Downloads” or “Subscriptions”. So I’d prefer to keep it available, but rename it appropriately, and do something different for ‘Popularity’.
Sounds good.
4 Likes
Understandable. However I think with a telemetry system like I’ve sketched you’ll get drastically better/much more reliable numbers, so if implemented the current “popularity” can be removed methinks.
