Re: [PD] Deken library management. Was: [pdconv16_r] Topics: Deken/Core Objects/Website/Community Involvement
> > Deken as it is right now, you > > pretty much have to know the name of the library you want to install, > > and what it does/what it contains. As a new user, I'd find that pretty > > daunting. > > very good point! > > > Thus, I'd propose: a list of keywords for the library (including object > > class names), version number, category (if applicable), author, and a > > short description. > > that would make a lot of sense. maybe this info could then be synced with > https://puredata.info/downloads/by-category/library so there would also be an > up-to-date online ressource (without the need of running Pd)? > Hello, See IOhannes's reponse to me about the -objects.txt. Also, yes, it would be good to have a centralized up-to-date resource with this information but I think it's also important that the same information or near the same information is available within Pd as well. Having to open a web-browser and dig around the internet for the information (which admittedly would be easier with an up-to-date centralized resource) just adds extra steps to the process when it's so much more convenient and intuitive to not have to leave Pd and get the information you want and download the library with just a few clicks or so. -- Derek Kwan www.derekxkwan.com ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Deken library management. Was: [pdconv16_r] Topics: Deken/Core Objects/Website/Community Involvement
> On 2016-10-31 13:11, Derek Kwan wrote: > > Thus, I'd propose: a list of keywords for the library (including object > > class names), version number, category (if applicable), author, and a > > short description. > > oh, you mean something like the "-objects.txt" file that you can upload > alongside your deken package? > https://github.com/pure-data/deken/issues/133 > > fgamsdr > IOhannes Yeah, something like that =). But also more info about the external library as a whole (description, etc.) that's also viewable within the plugin itself. I can search for something and come up with a big list of libraries, but as an end-user I can't be certain what I've actually found with libraryx-v0.2.0 and there isn't info that tells me why I should download libraryx over libraryz that's also in the same list of results and I can't see the -objects.txt from the plugin so I can't tell how closely libraryx fits what I actually am looking for (although this might be mitigated with a library description so I wouldn't actually need to see the whole -objects.txt within the plugin window or some sort of popup). -- Derek Kwan www.derekxkwan.com ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Deken library management. Was: [pdconv16_r] Topics: Deken/Core Objects/Website/Community Involvement
On 2016-10-31 13:11, Derek Kwan wrote: > Thus, I'd propose: a list of keywords for the library (including object > class names), version number, category (if applicable), author, and a > short description. oh, you mean something like the "-objects.txt" file that you can upload alongside your deken package? https://github.com/pure-data/deken/issues/133 fgamsdr IOhannes signature.asc Description: OpenPGP digital signature ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Re: [PD] Deken library management. Was: [pdconv16_r] Topics: Deken/Core Objects/Website/Community Involvement
> Deken as it is right now, you > pretty much have to know the name of the library you want to install, > and what it does/what it contains. As a new user, I'd find that pretty > daunting. very good point! > Thus, I'd propose: a list of keywords for the library (including object > class names), version number, category (if applicable), author, and a > short description. that would make a lot of sense. maybe this info could then be synced with https://puredata.info/downloads/by-category/library so there would also be an up-to-date online ressource (without the need of running Pd)? > Gesendet: Montag, 31. Oktober 2016 um 13:11 Uhr > Von: "Derek Kwan" <derek.x.k...@gmail.com> > An: "Fred Jan Kraan" <fjkr...@xs4all.nl> > Cc: pd-list@lists.iem.at > Betreff: Re: [PD] Deken library management. Was: [pdconv16_r] Topics: > Deken/Core Objects/Website/Community Involvement > > > It would help the discussion if there was an inventory of actual problems > > the metadata would solve. There was a discussion about this on the Github > > deken-list, which (probably) went nowhere because of this. > > This metadata would potentially solve issues with updates (I'll discuss > this later) and just general ease-of-use. Deken as it is right now, you > pretty much have to know the name of the library you want to install, > and what it does/what it contains. As a new user, I'd find that pretty > daunting. I don't know what external libraries are there for Pd, I don't > know what any of them do, I don't know when they were last updated so I > don't know how old these libraries are. Even as an experienced user, maybe > I'll forget which libraries have sample-length delays, or bandlimited > oscillators or limiters (you don't need to tell me this, I already know =P) > > At least with pd-extended, everything was just there and you could dig through > the Pd browser. In a post-extended world, we're just throwing users into the > deep > end and hoping for the best. At least in my experience, I've seen a lot of > people asking how to install x library or wondering what library they > can download for some certain functionality, and a lot of people just > resorting to pd-extended because it's easier. I think as contributing > members to the Pd community, it's our job (or at least it'd be nice) to > make things easier for newcomers. Heck, even in the pd-extended era, it > was kinda hard to tell what all the libraries did and what object > classes they had just from the sheer scale of it all. > > Taking a page from Processing, the Contribution Manager has a filter > search where you can look up keywords, the version number, a short > description of what the library does, and the author. Additionally, you > can install, update, and also remove from the same window. Like if I > type in "audio" into the filter, the list that used to display all the > libraries is just displaying Beads, Loom, and Minim. There's also a > dropdown menu to sort by category, such as Animation, GUI, Hardware, > etc. > > Thus, I'd propose: a list of keywords for the library (including object > class names), version number, category (if applicable), author, and a > short description. > > > > With the current update policy of Pd-vanilla (add new functionality without > > breaking the existing one), not much issues arise between the core and > > externals. The best strategy for building externals is to anticipate > > differences in vanilla versions, implement workarounds if possible or fail > > gracefully if needed. > > I suppose I'm more concerned about updates to external libraries so it > migth be a little off-topic =). But here's a case, say I have library x > v 2.0 and it's buggy as heck and a v3.0 happens to get uploaded. One > nice thing would be to have Deken tell me about that (esp if I have > something like 20 libraries installed on my computer, it gets kinda hard > to keep track of it all) but perhaps more importantly and realistically, > I'd like to be able to download the update without having to mess with > the current installation and not have to worry about duplicates. I'm > just trying to think of smarter library management in a post-extended > world and I suppose I'm thinking of pd-l2ork too and how to go about if > one library gets updated inbetween pd-l2ork versions, but this also > applies to using Pd Vanilla as well. > > > A version number would be a good idea, but how many external-packages depend > > on other entities than Pd-vanilla? Having more information available before > > downloading would be nice, and this could already be implemented as an > > extended deken-plugin. > > > > Debian packages also have d
Re: [PD] Deken library management. Was: [pdconv16_r] Topics: Deken/Core Objects/Website/Community Involvement
> It would help the discussion if there was an inventory of actual problems > the metadata would solve. There was a discussion about this on the Github > deken-list, which (probably) went nowhere because of this. This metadata would potentially solve issues with updates (I'll discuss this later) and just general ease-of-use. Deken as it is right now, you pretty much have to know the name of the library you want to install, and what it does/what it contains. As a new user, I'd find that pretty daunting. I don't know what external libraries are there for Pd, I don't know what any of them do, I don't know when they were last updated so I don't know how old these libraries are. Even as an experienced user, maybe I'll forget which libraries have sample-length delays, or bandlimited oscillators or limiters (you don't need to tell me this, I already know =P) At least with pd-extended, everything was just there and you could dig through the Pd browser. In a post-extended world, we're just throwing users into the deep end and hoping for the best. At least in my experience, I've seen a lot of people asking how to install x library or wondering what library they can download for some certain functionality, and a lot of people just resorting to pd-extended because it's easier. I think as contributing members to the Pd community, it's our job (or at least it'd be nice) to make things easier for newcomers. Heck, even in the pd-extended era, it was kinda hard to tell what all the libraries did and what object classes they had just from the sheer scale of it all. Taking a page from Processing, the Contribution Manager has a filter search where you can look up keywords, the version number, a short description of what the library does, and the author. Additionally, you can install, update, and also remove from the same window. Like if I type in "audio" into the filter, the list that used to display all the libraries is just displaying Beads, Loom, and Minim. There's also a dropdown menu to sort by category, such as Animation, GUI, Hardware, etc. Thus, I'd propose: a list of keywords for the library (including object class names), version number, category (if applicable), author, and a short description. > With the current update policy of Pd-vanilla (add new functionality without > breaking the existing one), not much issues arise between the core and > externals. The best strategy for building externals is to anticipate > differences in vanilla versions, implement workarounds if possible or fail > gracefully if needed. I suppose I'm more concerned about updates to external libraries so it migth be a little off-topic =). But here's a case, say I have library x v 2.0 and it's buggy as heck and a v3.0 happens to get uploaded. One nice thing would be to have Deken tell me about that (esp if I have something like 20 libraries installed on my computer, it gets kinda hard to keep track of it all) but perhaps more importantly and realistically, I'd like to be able to download the update without having to mess with the current installation and not have to worry about duplicates. I'm just trying to think of smarter library management in a post-extended world and I suppose I'm thinking of pd-l2ork too and how to go about if one library gets updated inbetween pd-l2ork versions, but this also applies to using Pd Vanilla as well. > A version number would be a good idea, but how many external-packages depend > on other entities than Pd-vanilla? Having more information available before > downloading would be nice, and this could already be implemented as an > extended deken-plugin. > > Debian packages also have dependencies listed, but that is quite a different > scale of complexity. > > Without some actual problems, it will be hard to devise a solution to solve > them. Here's a case: Say I have this piece that requires library1, library2,... up to libraryn that are all avaliable compiled for various platforms on deken. I'm on linux and I want to share this piece with a group of people who are on MacOS, Windows, Raspberry Pi's, etc. What's the best way to go about this? Potentially I can just include the binaries for every single platform and have one thing I can ship out, I can on my own make platform independent distributions and make those available, or potentially a third option (my proposed idea), have a package manifest with a list of the libraries and their build versions, and have deken handle the versioning and platform-specific binaries by handing the package manifest over to deken like how you can use a package.json file in a node.js project to contact a central repository and download everything with their proper versions via npm install. Especially if these patches with library dependencies I want to distribute are didactic material, I want it to be as easy and painless as possible, almost as easy as downloading pd-extended in the past. For the local vs global install issue , maybe this piece requires library3
