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.
Probably I should clarify. In my mind, raw data is meaningless. It is the information in that data that has meaning, and the meaning is not inherent in the data but rather emergent as the user plays a prime role. Data is objective. Information and meaning are subjective interpretations of objective data.
1 Like
It’s useful for knowing how many people have downloaded/subscribed to your plugin since you made it.
1 Like
Perhaps I should clarify as well. Being a developer myself, although not of Rack plugins (yet), I think I can easily put myself in a Rack developers’ shoes.
Let’s say that 4 years ago, I developed a plugin, call it “old and boring”, but it had the best reverb available at the time. And let’s say that 1 year ago I developed a plugin, call it “new and shiny”, that has a far superior reverb in it, that everyone is using and raving about, and nobody is using the “old and boring” anymore, because why should they.
But the numbers I get is that “old and boring” has FAR more downloads and subscriptions than “new and shiny”, simply because they were first and are oldest, even though I know for sure that everyone is now using “new and shiny” and nobody uses “old and boring”.
As a developer, looking at those numbers, I would think to myself: These numbers are meaningless and only reflects a historical reality/artifact. As a developer, the numbers I could use for something is: Right now “new and shiny” is being used X number of times and “old and boring” is hardly being used anymore, just as expected, and how I like it.
But maybe that’s just me…
And that’s what I’m not getting the usefulnes of. But that’s okay
Also to note that in my proposal, historical usage data can be surfaced, and show usage numbers of plugins and modules over time, as far back as wanted.
I find both approaches to be meaningful and useful. It isn’t an either/or choice. But, the reality is that the popularity data is all we have now and there is no indication whatsoever that we will have anything else from a systems level.
Again - they are just different things.
I agree with you that as an indication of ‘what are people using now?’ - the figure for ‘total number of downloads/subscriptions’ is pretty meaningless.
But while ‘what are people using now?’ is a good question to ask, and to know the answer to, it is not the only question there is.
“How many people have downloaded my thing since i made it?” is also a valid question. And that’s what the current popularity number shows us. It’s a number that constantly grows over time. I can legitimately say “Nearly 43k users have downloaded our MindMeld plugin since release” which might be useful in certain circumstances like a job interview or a talk for example.
A new popularity measurement would be module based rather than plugin based and it would be a number that could go up or down over time (depending whether particular modules become more or less popular over time). This data would also be very good to know - but it’s just a different data set from the other downloads number, it doesn’t replace it.
2 Likes
I would agree with you if these were things that people actively sought out on different web pages and downloaded. That would almost certainly indicate usage. However, given that most users today reflexively subscribe to all free plugins, whether they use them or not, because it’s very easy, I think the numbers are merely an inflated number indicating no such thing as usage, current popularity or such. And I don’t like inflated or misleading numbers, but sure, you can use them in an interview.
No, both. It should measure both. Maybe I should clarify that in my proposal.
Yes, that’s exactly the point. The whole idea is to get numbers that accurately reflect actual usage, and hence the best approximation to liking them or popularity. And they can obviously be stored for historical data, graphs, archeology etc.
Yes. I guess my argument is that it’s a vastly superior one, and given actual usage data I can’t see what accumulated download/subscription numbers, in the specific context of the Rack ecosystem, can really be used for.
I guess that’s what I’m arguing that it can I wouldn’t throw away the old numbers before the new system has been running for a while of course. Heck, the old numbers could just be a zip archive for download somewhere.
I think we can safely say that we don’t all derive the same meaning from data. I can only say what is meaningful and useful to me. Only you can say what is meaningful and useful to you. For either of us to try to say that our meaning is more meaningful that another’s seem counterproductive.
1 Like
Of course. We’re also trying an exercise in thinking what might be useful across the board, to a large number of users, and developers. But I get it that you and Steve think the currrent download/subscribe numbers are meaningful, even though I disagree, and there’s no physical law saying that we can’t keep both In the context of the current thread though, I think the focus is on users, perhaps especially new users, and how they might determine what plugins and modules to try out.
1 Like
Your argument against keeping the downloads number appears to be based on it not being a reliable indicator of usage or popularity. I’ve already agreed with you that it is not.
Once again though “What are people using now?” is not the only valid question.
2 Likes