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.
I think they are just different things…
As a developer, having a figure for “The total number of times our plugin has been downloaded/subscribed to” is good to know. And from what I understand from your proposed ‘popularity’ measurement - that number would be totally lost. Therefore the current ‘popularity’ figure should stay, but be renamed . I emphasise that this is useful data for a developer to know, and of negligible use to users.
Your proposed system for a ‘popularity’ measurement would be of far more use to users, and also good data for developers - regarding what people are using currently. With the caveat that, if I understand right, this new ‘popularity’ data could only start from the time the new measurement system is implemented - we could not get historical usage figures because that data isn’t available.
2 Likes
Ok, I see. I mean, it’s “since the dawn of time” and most people subscribe to almost everything, so I just have a hard time imagining what it could be useful for. But I’ll take your word for it
Yes.
As a developer, I find the current popularity data useful.
As a user, I find the current popularity data “meaningful”… I still believe that a new user could not go wrong by taking the time to try out the top N plugins to get a better feel for what more is available and possible. So, maybe data has meaning to some people and not to others, but it should not be deprecated in my opinion.