That’s my point exactly. And once a module gets “popular” (much used) that will turn into a self-enforcing loop.
I assume you also do not approve of reviews of books, movies, music gear, music, computer software, bicycles, audio equipment, restaurants, N95 masks, cell phones, etc?
In the spirit of data based assessment, I present the following. As background, when I retired almost 5 years ago from a large 40K student university, i was responsible for computer hardware and software usage tracking in the University Library, which was the most visited building on campus. As a director and manager, I set up software usage tracking for public computers, of which we had several hundred. Most of these were general purpose Windows computers, but I was personally responsible for specialty labs such as the “3D Animation Lab” and the “Digital Media Studio”. As things worked out, the 3D Lab was Windows machines as all 3D software ran on Windows, but less than half ran on Mac OS at the time. The Digital Media Studio computers were iMacs, mostly because of user preference for Macs in video and music editing. We only had Linux machines in research labs and server rooms, mostly.
So, for each computer and groups of computers I had commercial software which showed total number of logins, number of unique user logins, time of day of login and day of the week (we were a near 7x24 resource), how many times each title was launched, how long a title was used. Over the course of a year we are talking of millions (I think) of logins by very close to 100% of the number of enrolled students.
In addition to assessment of usage of what we had, we also did a computer based needs assessment survey where users could tell us what they liked, what they disliked and what they needed that we did not have. During most of my time there, we had Lynda.com video tutorial subscription where students could view very high quality tutorials on just about every software package we had (licensing and compliance was a job in itself).
The bottom line is that I could always back up my annual plans and assessments with very reliable and complete data.
So, in the same spirit, I spent a very brief amount of time this afternoon seeing what I could determine and summarize of how people find plugins and modules on VCV Rack.
For my sampling, I chose plugins that I know are heavily used and have been in the library for 3 years. What I found was a high-water mark of 178K unique installs for the most installed plugin. The 2nd most installed plugins had around 80K-100K installs, but the installs ranged from 43K to 100K in this tier.
From this, I would tentatively guess that the number of users was around 180K, assuming that almost everyone downloaded the top runner. But, otherwise it appears that no more than 60K on the average downloaded all of the top tier software, or about 33%. If we include all plugins, the number would probably be that less than 10% download every free module.
My PurrSoftware Meander module is 3 years old and has been downloaded by 14.3K users, or about 8% of users given the above assumptions.
Whereas the above does not say anything about how users found plugins, by and large they had to go seek each plugin they installed.
One could make the case that it would benefit the user to have a ranked list of plugins by installs as a starting point for finding most used. I’m not aware of any way to get such a ranking.
I would surmise that users would used improved search capabilities including more tags or meta-tags as well as capability descriptions;
I may have misunderstood or mistaken this data, so take it with a grain of salt.
Downloaded is all we got, but telemetry data saying how often each was instantiated (not counting for browser snashots (module == nullptr)) would be much better. If one were attempting to know how often various modules were intentionally “used”, that is.
btw, I thought you bowed out of this discussion yesterday
Interesting data that the “downloads” number seems somewhat useful now.
I operate in several parallel realities
I’m not sure how useful ‘downloaded’ module numbers are - those numbers generally seem to be based on the length of time they have been available in the library as much as anything.
Personally I have downloaded almost every free plugin and have probably never even instantiated around 50% of them. I like to have all the free plugins downloaded so I can open other people’s patches.
Number of instantiations over the last week/month/year/ever would be way more informative imo.
In reading these responses, a thought did come to mind which may be friendly to the original posters thinking. I branched it off into another topic: Paths to follow after Fundamental
I think it is very easy to guess who would be ranking in the top ten for those who have a little experience in the rack experience with the rack, I think it would be a list with very few variations, where the same modules would always be ranking.
I think a page (linked or not to the vcv rack) with reviews of specific modules and plugins would be more useful
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.
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?
Here is a cross-link to an applicable page from history for this topic.
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:
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.
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.
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.
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.
Yeah, let’s keep it here where it belongs.
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.