hi all,
i've just setup a new (experimental) webservice, that shows some graph about trends in the usage of Pd, based on deken queries.
as we all know, deken - Pd's built in package manager - can be used to query https://deken.puredata.info/ for available packages.
what some of you might now know is that deken sends the following information along with the request:
all this information is send as the "user agent" string (just like, when you access a webpage with your favourite browser, it will send its version and whatnot, e.g. "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0").
sidenote: i think myself of rather privacy aware, and do not think that collecting any of these data is problematic (nor is sending them from within Pd).
also, because this is how the internet works, the web server knows about your IP (and thus can make some educated guess about the country you are currently accessing a webpage from), and whether you are using an encrypted channel (https) or not (http); and of course the actual query.
i've finally decided to make this data public (and somewhat useful), by extracting some time-series and creating nice graphs from them.
these are now available on https://deken.puredata.info/trends
the data should get updated automatically. (since the data already covers about 7 years, it might look like it's not being updated though; but this is about seeing long-term *trends*, rather than short-term hypes, so I don't think it is a problem)
# data skew
the input data for the trend series is searches for externals via Pd's built-in package manager. this means, that specific use cases of Pd might not show up in the data at all. e.g. some Linux users might just prefer to install externals via their package manager (and do all searches there), so they won't be represented here at all.
Pd distributions that ship with a lot of externals, will not show up (as the users will not have a need to search for externals). esp. Pd-l2ork and Purr-Data do not show up, as they do not allow deken search (and there's some binary incompatibility, so that's a good thing) Plug Data does not show up either, even though you *can* use deken with it, because Plug Data does not directly query our web server for caching reasons.
early versions of deken would not send a specific user agent string (and use just the default one of Tcl/Tk), that's why you sometimes see labels like "Darwin?" or "i386?" - these values are just educated guesses, based on the user agent string and the the time when the queries occurred)
# absolute vs relative data
the data presented is relative (in percent). you can get graphs with absolute values by clicking on the images.
# oddities
the absolute data is very seasonal (whereas the relative representation is more or less stable). this *might* have to do with Pd being primarily used in educational contexts (with holidays in between, where the Pd is little used). but really, idk.
the other thing i found odd was that up to 2020 a considerable amount of the webtraffic (between 50% and 70%!) was using https. after that this dropped to between 5-10%. after some investigation i found that this has mostly to do with us upgrading the Tcl/Tk version included with Pd on macOS: up to Pd-0.51 (or so), the included Tcl/Tk was able to use system installed tcl-libraries, and macOS comes with a library that allows us to do https. newer versions of Tcl/Tk can no longer use this library, and since we do not ship our own, this means that the traiffic is degraded to http :-(
cheers,
gasdmr IOhannes
Great work, very valuable info, thanks IO!
Le lun. 28 juil. 2025 à 17:02, IOhannes m zmoelnig via Pd-list < pd-list@lists.iem.at> a écrit :
hi all,
i've just setup a new (experimental) webservice, that shows some graph about trends in the usage of Pd, based on deken queries.
as we all know, deken - Pd's built in package manager - can be used to query https://deken.puredata.info/ for available packages.
what some of you might now know is that deken sends the following information along with the request:
- the Tcl/Tk version used (e.g. "8.6.10")
- the Pd version used (e.g. "0.55-2")
- the deken version used (e.g. "0.9.18")
- the deken architecture of Pd (e.g. "Windows-amd64-32")
all this information is send as the "user agent" string (just like, when you access a webpage with your favourite browser, it will send its version and whatnot, e.g. "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0").
sidenote: i think myself of rather privacy aware, and do not think that collecting any of these data is problematic (nor is sending them from within Pd).
also, because this is how the internet works, the web server knows about your IP (and thus can make some educated guess about the country you are currently accessing a webpage from), and whether you are using an encrypted channel (https) or not (http); and of course the actual query.
i've finally decided to make this data public (and somewhat useful), by extracting some time-series and creating nice graphs from them.
these are now available on https://deken.puredata.info/trends
the data should get updated automatically. (since the data already covers about 7 years, it might look like it's not being updated though; but this is about seeing long-term *trends*, rather than short-term hypes, so I don't think it is a problem)
# data skew
the input data for the trend series is searches for externals via Pd's built-in package manager. this means, that specific use cases of Pd might not show up in the data at all. e.g. some Linux users might just prefer to install externals via their package manager (and do all searches there), so they won't be represented here at all.
Pd distributions that ship with a lot of externals, will not show up (as the users will not have a need to search for externals). esp. Pd-l2ork and Purr-Data do not show up, as they do not allow deken search (and there's some binary incompatibility, so that's a good thing) Plug Data does not show up either, even though you *can* use deken with it, because Plug Data does not directly query our web server for caching reasons.
early versions of deken would not send a specific user agent string (and use just the default one of Tcl/Tk), that's why you sometimes see labels like "Darwin?" or "i386?" - these values are just educated guesses, based on the user agent string and the the time when the queries occurred)
# absolute vs relative data
the data presented is relative (in percent). you can get graphs with absolute values by clicking on the images.
# oddities
the absolute data is very seasonal (whereas the relative representation is more or less stable). this *might* have to do with Pd being primarily used in educational contexts (with holidays in between, where the Pd is little used). but really, idk.
the other thing i found odd was that up to 2020 a considerable amount of the webtraffic (between 50% and 70%!) was using https. after that this dropped to between 5-10%. after some investigation i found that this has mostly to do with us upgrading the Tcl/Tk version included with Pd on macOS: up to Pd-0.51 (or so), the included Tcl/Tk was able to use system installed tcl-libraries, and macOS comes with a library that allows us to do https. newer versions of Tcl/Tk can no longer use this library, and since we do not ship our own, this means that the traiffic is degraded to http :-(
cheers,
gasdmr IOhannes -- please do not CC me for list-emails
pd-list@lists.iem.at - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/FXCP2RBI4R...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Wow - thanks IOhannes, this is amazing!
hi all,
i've just setup a new (experimental) webservice, that shows some graph about trends in the usage of Pd, based on deken queries.
as we all know, deken - Pd's built in package manager - can be used to query https://deken.puredata.info/ for available packages.
what some of you might now know is that deken sends the following information along with the request:
- the Tcl/Tk version used (e.g. "8.6.10")
- the Pd version used (e.g. "0.55-2")
- the deken version used (e.g. "0.9.18")
- the deken architecture of Pd (e.g. "Windows-amd64-32")
all this information is send as the "user agent" string (just like, when you access a webpage with your favourite browser, it will send its version and whatnot, e.g. "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0").
sidenote: i think myself of rather privacy aware, and do not think that collecting any of these data is problematic (nor is sending them from within Pd).
also, because this is how the internet works, the web server knows about your IP (and thus can make some educated guess about the country you are currently accessing a webpage from), and whether you are using an encrypted channel (https) or not (http); and of course the actual query.
i've finally decided to make this data public (and somewhat useful), by extracting some time-series and creating nice graphs from them.
these are now available on https://deken.puredata.info/trends
the data should get updated automatically. (since the data already covers about 7 years, it might look like it's not being updated though; but this is about seeing long-term *trends*, rather than short-term hypes, so I don't think it is a problem)
# data skew
the input data for the trend series is searches for externals via Pd's built-in package manager. this means, that specific use cases of Pd might not show up in the data at all. e.g. some Linux users might just prefer to install externals via their package manager (and do all searches there), so they won't be represented here at all.
Pd distributions that ship with a lot of externals, will not show up (as the users will not have a need to search for externals). esp. Pd-l2ork and Purr-Data do not show up, as they do not allow deken search (and there's some binary incompatibility, so that's a good thing) Plug Data does not show up either, even though you *can* use deken with it, because Plug Data does not directly query our web server for caching reasons.
early versions of deken would not send a specific user agent string (and use just the default one of Tcl/Tk), that's why you sometimes see labels like "Darwin?" or "i386?" - these values are just educated guesses, based on the user agent string and the the time when the queries occurred)
# absolute vs relative data
the data presented is relative (in percent). you can get graphs with absolute values by clicking on the images.
# oddities
the absolute data is very seasonal (whereas the relative representation is more or less stable). this *might* have to do with Pd being primarily used in educational contexts (with holidays in between, where the Pd is little used). but really, idk.
the other thing i found odd was that up to 2020 a considerable amount of the webtraffic (between 50% and 70%!) was using https. after that this dropped to between 5-10%. after some investigation i found that this has mostly to do with us upgrading the Tcl/Tk version included with Pd on macOS: up to Pd-0.51 (or so), the included Tcl/Tk was able to use system installed tcl-libraries, and macOS comes with a library that allows us to do https. newer versions of Tcl/Tk can no longer use this library, and since we do not ship our own, this means that the traiffic is degraded to http :-(
cheers,
gasdmr IOhannes -- please do not CC me for list-emails
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/FXCP2RBI4R...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Hi,
On 28/07/2025 23:02, IOhannes m zmoelnig via Pd-list wrote:
i've just setup a new (experimental) webservice, that shows some graph about trends in the usage of Pd, based on deken queries.
This is really cool, thanks for sharing the anonymous data.
As well as the data you have shared, it is often useful for developers to know what users actually want. In lieu of actually speaking to human beings (horrifying), one way to accomplish this is to look at search volume data. I think it would be useful for Pd developers to be able to see a) which packages people are installing the most b) what else people are searching for in the deken search bar (especially where no results are found).
Summary:
exist yet. 3. Users rejoice.
Cheers,
Chris.
thanks all for your feedback.
i just realized, that i never answered any of this so.
On 30/07/2025 06:29, Chris McCormick wrote:
Hi,
On 28/07/2025 23:02, IOhannes m zmoelnig via Pd-list wrote:
i've just setup a new (experimental) webservice, that shows some graph about trends in the usage of Pd, based on deken queries.
This is really cool, thanks for sharing the anonymous data.
As well as the data you have shared, it is often useful for developers to know what users actually want. In lieu of actually speaking to human beings (horrifying), one way to accomplish this is to look at search volume data. I think it would be useful for Pd developers to be able to see a) which packages people are installing the most
the data that i'm currently analysing, does not say anything about what people are *installing*. i'm only recording the search queries themselves. (obviously the downloads are recorded in the logs of the relevant webserver as well (which is really distinct from the deken frontend), but those logfiles are not kept very long. i currently only have 2 weeks of data for this.
b) what else people are searching for in the deken search bar >
i'm not entirely sure about the actual usefulness of this.
here's a random excerpt of search words (splitting all search queries of the last 7 years into single words, removing duplicates and then randomizing the list; finally picking a handful)
colorSquare
compress_limit*
*simplex*
timeS
applez
stretcher
es5encoder~
/home/oh/Escriptori/OH.R+D/musIA/Code/ANN.Pd/ann-master
bowed~
RTC
solus
shel
xenakis
C03.zipper.noise.pd
adsp
frid
Live-Electronics-Tutorials
csm
pixie
b07
writ
sgvisu~
multi*
tlse
iemlib/iemlib2
v0.0.0-alpha
as you can see, people are making typos, searching for version number or even files (presumably on their own disk).
i just replayed these search-queries, and of the 26 queries, only 6 gave any result.
looking specifically at multiword queries, here are a few gems (after q quick glance at about 6000 of these queries):
sudo apt-get install libgstreamer-plugins-base0.10-dev
sugn wave
suma de frecuencias
super collider
surround patches
svn co
https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-gui-rewrite/0.43/startup/
pd help browser
alexandre torres porres
Gem/0.94 (deken-archive for macOS Intel/64bit (macOS10.12+))
(i'm afraid, only the very last of these queries returned anything; and only because the "easyflow" library has a [for] object - probably not what the user was looking for)
so this probably tells us a bit about the expectations of people when they encounter a search field (and thus a bit about the shortcomings of deken as a search engine)
(especially where no results
are found).
this one might turn out trickier than expected. i only have the webserver logfiles, that logs the actual queries and how those queries were served. the only information about the result we can extract from the logs, is the status code (200, also for empty results) and the number of bytes returned. obviously empty results require less bytes than many results. but there's a bit of a grey area.
Summary:
- Developers review search interest data.
- Developers build the things that users are looking for that don't
exist yet. 3. Users rejoice.
do you really think so?
i would have thought that the Pd ecosystem is more like the classical open source world ("you need something yourself, but it's not available; you implement it; then you share it") rather than (somewhat idealized) commercial software enterprises ("you do a market analysis of what people want; you implement it; then you sell it"). but that might very well be because of my personal background.
but anyhow: no i had no plans to publish statistics about the search terms and downloads. most likely because for me this has a "(a)social media" smell, where software contributions get "ranked", making developers of popular packages "better" than those of niche packages.
the idea about statistics for empty search terms is interesting, but i'm not sure how much work is required to clean up the data from simple typos / invalid queries, to get something meaningful.
gmdsar IOhannes
On 24/08/2025 01:57, IOhannes m zmölnig via Pd-list wrote:
On 30/07/2025 06:29, Chris McCormick wrote: here's a random excerpt of search words (splitting all search queries of the last 7 years into single words, removing duplicates and then randomizing the list; finally picking a handful)
i just replayed these search-queries, and of the 26 queries, only 6 gave any result.
The ones that give no result are the interesting ones. The user is saying "this is what I want" and getting nothing in return.
looking specifically at multiword queries, here are a few gems (after q quick glance at about 6000 of these queries):
sudo apt-get install libgstreamer-plugins-base0.10-dev sugn wave suma de frecuencias super collider surround patches svn co https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/ pd-gui-rewrite/0.43/startup/ pd help browser alexandre torres porres Gem/0.94 (deken-archive for macOS Intel/64bit (macOS10.12+))
(i'm afraid, only the very last of these queries returned anything; and only because the "easyflow" library has a [for] object - probably not what the user was looking for)
Ranking the queries that returned nothing by frequency is what is interesting.
so this probably tells us a bit about the expectations of people when they encounter a search field (and thus a bit about the shortcomings of deken as a search engine)
Yep, that's useful information about people's expectations from Deken and maybe ways it could be improved to meet or calibrate expectations.
(especially where no results
are found).
this one might turn out trickier than expected. i only have the webserver logfiles, that logs the actual queries and how those queries were served. the only information about the result we can extract from the logs, is the status code (200, also for empty results) and the number of bytes returned. obviously empty results require less bytes than many results. but there's a bit of a grey area.
Ah ok, understood.
- Developers review search interest data.
- Developers build the things that users are looking for that don't
exist yet. 3. Users rejoice.
do you really think so?
i would have thought that the Pd ecosystem is more like the classical open source world ("you need something yourself, but it's not available; you implement it; then you share it") rather than (somewhat idealized) commercial software enterprises ("you do a market analysis of what people want; you implement it; then you sell it"). but that might very well be because of my personal background.
Yes I agree that is how the Pd ecosystem is. I would say that process is sub-optimal for non-technical users. I guess we are privileged to be able to solve our own problems by writing code, whereas for the vast majority of Pd users that's a significant undertaking and they rely on volunteer developers to improve things.
I should say, I'm not proposing anybody sell anything.
but anyhow: no i had no plans to publish statistics about the search terms and downloads. most likely because for me this has a "(a)social media" smell, where software contributions get "ranked", making developers of popular packages "better" than those of niche packages.
Yes, agree, that's gross.
the idea about statistics for empty search terms is interesting, but i'm not sure how much work is required to clean up the data from simple typos / invalid queries, to get something meaningful.
Yep fair enough. I understand it would take work.
Typos and invalid queries are a very useful signal though. They tell you where users are making mistakes or using Deken in a way it's not designed for. The frequency of common typos and invalid queries tells you how sharp the problem is = how bad your own UI/documention is, which is causing the issue for those users.
I think even the list of 6000 terms ranked by frequency would be interesting (even if you filtered out actual package names).
Anyway, I know you spend a lot of time and effort maintaining these systems. I'm grateful for that and definitely not asking you to do more work than you already do! It was just a random idea that I thought might help end-users of Pd in some way.
Cheers,
Chris.
On 25/08/2025 10:58, Chris McCormick wrote:
On 24/08/2025 01:57, IOhannes m zmölnig via Pd-list wrote:
Ranking the queries that returned nothing by frequency is what is interesting.
i still haven't done my homework, and checked the actual data, but:
I believe that you are not concerned about trends here at all ("there has been a steep decline of people searching in vain for 'shel' in the past 3 years"), but about current stats.
otoh, *I* am really interested in trend data for now ("how fast do people adopt to new versions of Pd?" "do I need to provide Pd64 packages?")
I do not really see how the search frequency can be turned into trends (yes, google can do that; but that doesn't scale down).
I think even the list of 6000 terms ranked by frequency would be interesting (even if you filtered out actual package names).
that's of course the other thing: I would like the statistics to be collected automatically. i *do not* want to manually filter out package names. (apart from that: how do we determine what a package name is? "zexy" and "else" obviously are. but what about "gge", "tlse"?).
i might produce a one-off list of search terms and send it to the mailinglist, though. maybe somebody can convince me that they got any "actually useful" insights from that :-)
gmsadr IOhannes
[...]
otoh, *I* am really interested in trend data for now ("how fast do people adopt to new versions of Pd?" "do I need to provide Pd64 packages?")
Off-topic, but: Yes, please do! :)
On 8/25/25 23:23, IOhannes m zmölnig via Pd-list wrote:
On 25/08/2025 10:58, Chris McCormick wrote:
On 24/08/2025 01:57, IOhannes m zmölnig via Pd-list wrote:
Ranking the queries that returned nothing by frequency is what is interesting.
i still haven't done my homework, and checked the actual data.
ok, so I've finally done my homework:
attached you will find one week of sorted query strings (collected from 2025-08-10 to 2025-08-16) that did not return any results.
no attempt is made to group queries from the same user (so if you taped in "wtf" and hit the Search button 20 times, then you will be the winner!)
in the "Find externals" dialog you can select whether you want to search for "libraries", "objects" or "both". those three options are split into separate files.
afaict, this is the data that was asked for.
so now: could anybody tell me what useful information you can extract from this data? (not just theoretically; what useful info **is** there ?)
esp. what data is there that is useful for an external developer (as opposed to the maintainers of the deken search)
gdasmr IOhannes
On 27/08/2025 08:06, IOhannes m zmoelnig via Pd-list wrote:
so now: could anybody tell me what useful information you can extract from this data? (not just theoretically; what useful info **is** there ?)
i think that perhaps the search bar should auto-contain all wildcards.
if i search "vst" i'll be happy to get vstplugin~ as a result instead of nothing.
On 27/08/2025 19:06, IOhannes m zmoelnig via Pd-list wrote:
attached you will find one week of sorted query strings (collected from 2025-08-10 to 2025-08-16) that did not return any results. afaict, this is the data that was asked for.
Thanks!
so now: could anybody tell me what useful information you can extract from this data? (not just theoretically; what useful info **is** there ?)
esp. what data is there that is useful for an external developer (as opposed to the maintainers of the deken search)
Why are you not interested in data that is useful for the maintainers of the deken search?
Clearly people are searching for 'freeverb' - why is it not returning the freeverb external? The intent of the user is obvious. How can the tool be updated to better serve the user?
"freeverd~" - soundex and or metaphone search could help the user.
"sigmund" - this could match against a list of internals: "did you mean sigmund~? It is built in to Pd already and you don't have to install it."
"panorama*" - if I go to deken.puredata.info and search for panorama and *panorama* in all 3 boxes nothing shows up. This seems like a useful thread for an external developer to follow up. Maybe people are looking for spatialization externals? Intriguing.
"opencv" - is there any existing opencv external? Seems like a useful signal for externals developers.
etc.
This is one week of data and already seems like it could improve the experience of Pd users who searched during that week. To me it seems likely that a month or more of data could provide good insights for improving the Pd ecosystem for end users.
I'm not saying this data should be gospel, or that definite hard conclusions should be drawn from it. I am saying it's a useful signal for developers, both yourself as the maintainer of deken, and people building externals and libraries.
Cheers,
Chris.
Clearly people are searching for 'freeverb' - why is it not returning the freeverb external? The intent of the user is obvious. How can the tool be updated to better serve the user?
Yes. I think this is a good argument for using wildcard search by default. We can add a checkbox for people who only want exact matches.
"panorama*" - if I go to deken.puredata.info and search for panorama and *panorama* in all 3 boxes nothing shows up. This seems like a useful thread for an external developer to follow up. Maybe people are looking for spatialization externals? Intriguing.
"opencv" - is there any existing opencv external? Seems like a useful signal for externals developers.
Honestly, I don't think anyone will write an external based on some "market data". We typically write externals because we find them useful or interesting and then make them available to other people.
esp. what data is there that is useful for an external developer (as opposed to the maintainers of the deken search)
Why are you not interested in data that is useful for the maintainers of the deken search?
simple: because that is practically only me (kudos to you of course, but in reality there have not been many contributions by others in the last decade) and I do not need to *publish* statistics about the queries, because i can access them just so. obviously i haven't done that myself, so this entire thread is a good motivation :-)
but if I were to invest time to publish such data, I would like to see benefits for other people that they can act on (short of nagging other people).
On 8/28/25 10:18, Christof Ressi wrote:
Clearly people are searching for 'freeverb' - why is it not returning the freeverb external? The intent of the user is obvious. How can the tool be updated to better serve the user?
Yes. I think this is a good argument for using wildcard search by default. We can add a checkbox for people who only want exact matches.
indeed. i do want people to be able to do exact matches (with wildcards and what not). but allowing the user to check whether they want to do a fuzzy search or an exact search sounds like the best idea.
should a fuzzy search also allow for soundex? (that's going to be more tricky. there's a tcl module in the tcllib, but we don't ship this with Pd; if we want to do the soundex matching on the server, we need to signal that in the query... it's easy, but right now the query is even trivial :-))
gfdmsr IOhannes
Em seg., 25 de ago. de 2025 às 05:58, Chris McCormick chris@mccormick.cx escreveu:
but anyhow: no i had no plans to publish statistics about the search terms and downloads. most likely because for me this has a "(a)social media" smell, where software contributions get "ranked", making developers of popular packages "better" than those of niche packages.
Yes, agree, that's gross.
Well, it is, but it looks like it's also a narrow perspective that doesn't necessarily dominates. I'll just say, I'd love to have access to the same statistics for my packages just so I get a good clear data on what's going on. Like, are people in China using my stuff? That's cool, maybe I'll try and connect with them. You know, whatever... Many libraries are from the extended libraries, are people still relying on them to keep some old patches alive? Are people being able to follow and adopt new stuff?
We got a good picture on "all externals", but I bet developers would like to see what's really the case for specific packages... and that is a concern that comes before comparing between each other to see "who wins the most number of likes content".
cheers
One possible solution could be to only show the download statistics to puredata.info members (= people who upload to Deken)
On 26.08.2025 21:46, Alexandre Torres Porres wrote:
Em seg., 25 de ago. de 2025 às 05:58, Chris McCormick chris@mccormick.cx escreveu:
> but anyhow: no i had no plans to publish statistics about the search > terms and downloads. > most likely because for me this has a "(a)social media" smell, where > software contributions get "ranked", making developers of popular > packages "better" than those of niche packages. Yes, agree, that's gross.
Well, it is, but it looks like it's also a narrow perspective that doesn't necessarily dominates. I'll just say, I'd love to have access to the same statistics for my packages just so I get a good clear data on what's going on. Like, are people in China using my stuff? That's cool, maybe I'll try and connect with them. You know, whatever... Many libraries are from the extended libraries, are people still relying on them to keep some old patches alive? Are people being able to follow and adopt new stuff?
We got a good picture on "all externals", but I bet developers would like to see what's really the case for specific packages... and that is a concern that comes before comparing between each other to see "who wins the most number of likes content".
cheers
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/R4AZBUKIDH...
To unsubscribe send an email topd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management ->https://lists.iem.at/
On 27/08/2025 04:15, Christof Ressi wrote:
One possible solution could be to only show the download statistics to puredata.info members (= people who upload to Deken)
Another possibility is a query-able interface that doesn't actually publish package stats, but the interested author could type in their package name to get stats.
Cheers,
Chris.
On 8/26/25 21:46, Alexandre Torres Porres wrote:
Well, it is, but it looks like it's also a narrow perspective that doesn't necessarily dominates. I'll just say, I'd love to have access to the same statistics for my packages just so I get a good clear data on what's going on. Like, are people in China using my stuff?
i don't think i will ever try to publish JOINed queries (as in: "how many people in *china* download *else*" or "how many users of *macOS* use *Pd-0.50*" or "who is this guy from *brazil* who keeps asking for *Gem* to run with *Pd-0.41* on their *macOS/Sequioa*").
Many libraries are from the extended libraries, are people still relying on them to keep some old patches alive?
that might be interesting indeed.
but what *I* am interested for now is: what would you make of it, if people still have a need for e.g. "jasch_lib"?
I mean: if I have a piece from 2006, that I haven't played since then and now want to perform it again, chances are that I will need some old objects (even if just for verifying that my migration to Pd-0.56 is still doing what it should). there's nothing wrong with that. (but i seriously doubt that it will make any statistical impact, if I do this 3 times, to setup my laptop (twice, because i botched it) and the laptop of the performer).
so what are the *possible* conclusions, if you see that people look for "jasch_lib"?
people would probably still look for "jasch_lib", if their patch depends on that library. the mere existance of [strlen] in some other library doesn't mean that it behaves the same)
We got a good picture on "all externals", but I bet developers would like to see what's really the case for specific packages...
letme rephrase my concern: if you see that your external hasn't had any downloads for the last 24 months, would you stop publishing it (since nobody cares anyhow)? and what if somebody *then* needs it desperately to perform their piece on their new hardware?
i somewhat understand the eagerness to see the performance of your own "product". i often look for that information for my own packages (e.g. on pypi). but to be honest, it is mostly to satisfy my own ego. and the practical implications are nil.
gfmasdr IOhannes
i somewhat understand the eagerness to see the performance of your own "product". i often look for that information for my own packages (e.g. on pypi). but to be honest, it is mostly to satisfy my own ego. and the practical implications are nil.
Seeing one's library being adopted can be a significant motivating factor, though. However, I totally see the danger of gamification and social competition, that's why I would be totally ok with not showing any kind of comparison or ranking.
gfmasdr IOhannes
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/VMHPNWNVB3...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/
Em qua., 27 de ago. de 2025 às 07:17, IOhannes m zmoelnig via Pd-list < pd-list@lists.iem.at> escreveu:
i don't think i will ever try to publish JOINed queries (as in: "how many people in *china* download *else*" or "how many users of *macOS* use *Pd-0.50*" or "who is this guy from *brazil* who keeps asking for *Gem* to run with *Pd-0.41* on their *macOS/Sequioa*").
Hmmm, I get it, everything we get to see is published by you, so you have to work on it and I get how all combinations would be crazy. But I thought and I could suggest people could be able to do some research. There was a suggestion to allow members to do that, and that seems reasonable.
letme rephrase my concern: if you see that your external hasn't had any downloads for the last 24 months, would you stop publishing it (since nobody cares anyhow)?
I for one wouldn't. I'm cursed and doomed to develop pd externals 'til the day I die, or something weird/terrible happens.
i somewhat understand the eagerness to see the performance of your own "product". i often look for that information for my own packages (e.g. on pypi). but to be honest, it is mostly to satisfy my own ego. and the practical implications are nil.
I just think this could be a good tool for analyzing the ecosystem beyond what you are offering. I wrote a paper essay these days (and it got rejected for the PdMaxCon, as they didn't seem to be keen on essays) that talked a lot about the history of Pd and stuff. This would have been an amazing tool for research and analysis to help me with that research. I still wanna work on it and publish it as an essay somewhere.
I'm kind of in a rush with the PdMaxCon trip coming up next week and I don't have much time to sit and make a strong case right now, so I'll just give a quick opinion. I think there are more benefits than 'risks/hazard/damage' in being able for us developers to be able to analyze this data in more detail. Even if it comes down to being "ego driven cool".
I had to look what "pypi" is... as I see it, it's an example of another ecosystem that doesn't have a problem in making download and usage statistics available, which is kind of my point. I don't think the idea there is only to attend to people's egos, but make researchers and developers understand and analyze the trends. I don't wanna dismiss the concerns, and maybe I'm just not really getting them. Or maybe it's all a matter of opinion and this is mine.
cheers
Le 27/08/2025 à 19:16, Alexandre Torres Porres a écrit :
Em qua., 27 de ago. de 2025 às 07:17, IOhannes m zmoelnig via Pd-list <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> escreveu:
i don't think i will ever try to publish JOINed queries (as in: "how many people in *china* download *else*" or "how many users of *macOS* use *Pd-0.50*" or "who is this guy from *brazil* who keeps asking for *Gem* to run with *Pd-0.41* on their *macOS/Sequioa*").
Hmmm, I get it, everything we get to see is published by you, so you have to work on it and I get how all combinations would be crazy. But I thought and I could suggest people could be able to do some research. There was a suggestion to allow members to do that, and that seems reasonable.
Publishing all data would create a huge privacy problem, imo.
Cheers c
On 27/08/2025 20:41, cyrille henry wrote:
Publishing all data would create a huge privacy problem, imo.
thanks cyrille. your email reminded me, that there is one thing I might have not made clear in all my arguing (and which might not have been obvious for a global community).
the deken.puredata.info and puredata.info servers are physically located in austria. as such, we are bound by european laws on what we may do. in this context, the interesting law is the GDPR [1], which restricts which data we may collect and publish.
mgrd IOhannes (who is really happy that we have the GDPR)
That's very cool! Some of the data is quite suprising. For example, I didn't expect that there are about as many Windows users as macOS users.
I agree with Chris that it would be cool to see package download statistics. Is this is something that is planned for the future?
Cheers,
Christof
On 28.07.2025 17:02, IOhannes m zmoelnig via Pd-list wrote:
hi all,
i've just setup a new (experimental) webservice, that shows some graph about trends in the usage of Pd, based on deken queries.
as we all know, deken - Pd's built in package manager - can be used to query https://deken.puredata.info/ for available packages.
what some of you might now know is that deken sends the following information along with the request:
- the Tcl/Tk version used (e.g. "8.6.10")
- the Pd version used (e.g. "0.55-2")
- the deken version used (e.g. "0.9.18")
- the deken architecture of Pd (e.g. "Windows-amd64-32")
all this information is send as the "user agent" string (just like, when you access a webpage with your favourite browser, it will send its version and whatnot, e.g. "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0").
sidenote: i think myself of rather privacy aware, and do not think that collecting any of these data is problematic (nor is sending them from within Pd).
also, because this is how the internet works, the web server knows about your IP (and thus can make some educated guess about the country you are currently accessing a webpage from), and whether you are using an encrypted channel (https) or not (http); and of course the actual query.
i've finally decided to make this data public (and somewhat useful), by extracting some time-series and creating nice graphs from them.
these are now available on https://deken.puredata.info/trends
the data should get updated automatically. (since the data already covers about 7 years, it might look like it's not being updated though; but this is about seeing long-term *trends*, rather than short-term hypes, so I don't think it is a problem)
# data skew
the input data for the trend series is searches for externals via Pd's built-in package manager. this means, that specific use cases of Pd might not show up in the data at all. e.g. some Linux users might just prefer to install externals via their package manager (and do all searches there), so they won't be represented here at all.
Pd distributions that ship with a lot of externals, will not show up (as the users will not have a need to search for externals). esp. Pd-l2ork and Purr-Data do not show up, as they do not allow deken search (and there's some binary incompatibility, so that's a good thing) Plug Data does not show up either, even though you *can* use deken with it, because Plug Data does not directly query our web server for caching reasons.
early versions of deken would not send a specific user agent string (and use just the default one of Tcl/Tk), that's why you sometimes see labels like "Darwin?" or "i386?" - these values are just educated guesses, based on the user agent string and the the time when the queries occurred)
# absolute vs relative data
the data presented is relative (in percent). you can get graphs with absolute values by clicking on the images.
# oddities
the absolute data is very seasonal (whereas the relative representation is more or less stable). this *might* have to do with Pd being primarily used in educational contexts (with holidays in between, where the Pd is little used). but really, idk.
the other thing i found odd was that up to 2020 a considerable amount of the webtraffic (between 50% and 70%!) was using https. after that this dropped to between 5-10%. after some investigation i found that this has mostly to do with us upgrading the Tcl/Tk version included with Pd on macOS: up to Pd-0.51 (or so), the included Tcl/Tk was able to use system installed tcl-libraries, and macOS comes with a library that allows us to do https. newer versions of Tcl/Tk can no longer use this library, and since we do not ship our own, this means that the traiffic is degraded to http :-(
cheers,
gasdmr IOhannes
pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/FXCP2RBI4R...
To unsubscribe send an email to pd-list-leave@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/