hi, (maybe this is of general interest for pd users?) speaking of lists, I once did a similar thing some years ago, collecting 2682 objects. the list is far away from being complete or up to date... http://www.parasitaere-kapazitaeten.net/files/GENERAL_ALL.csv_.txt marius.
2009/2/20 João Pais jmmmpais@googlemail.com:
Hans-Christoph Steiner wrote: I definitely agree that we should have libraries organized based on a topic. There is nothing stopping anyone from doing this. There is tons of code that could be easily taking and stuck into new libraries organized around concepts.
hmm, that matches with what I was proposing (still on a private level) for the new categories of documentating pd-ext objects. although some people might not like not having their objects in their personal folder, it would really make information more easily to come by - fyi, I think in the latest object list I've made, there are ~1200 externals (objects + abstractions).
I would go to the extra step and and follow yves' suggestions try to ask some developpers to change the names of some objects to avoid name clashes - if that's possible anyway, after all these years of programming.
I can't contribute with code because I can't code, but I can write mails and give (sometimes good) ideas. To remind how big the task is, I attach here the list of pd-ext objects I've done some months ago (as a first step to try to get an updated documentation for pd-ext).
(maybe this is of general interest for pd users?) speaking of lists, I once did a similar thing some years ago, collecting 2682 objects. the list is far away from being complete or up to date... http://www.parasitaere-kapazitaeten.net/files/GENERAL_ALL.csv_.txt
I already made my one available several times on the list - whenever the question "how many objects are in pd-ext" comes -, but probably it wasn't that popular. 2682 objects? when I check the properties of the extra folder (windows), I get 2666 files - bear in mind that there are several repeatitions (many objects are repeated in flatspace), and other files aren just secondary material, and some objects don't work. did you sort out repetitions or something?
how did you extract this list? I'm willing to (try to) put some effort in having a process that documents pd-ext efficiently, and that could run as automatized as possible. here is also something I wrote some days ago to HC:
About the documentation: I don't have much time (or mood) these days to get back to updating the 0.INTRO file, but I've been listing some ideas to automatise this task. In case you don't remember, some time ago I did the attached excel file - afaik, it is the most complete pd-ext object list so far. But it was done by hand - open helpfile, copy-paste, etc. My idea was to make a script that scans the extra folder, extracts the file names and groups them into the existing categories (math, glue, etc), and also lists the folder where they are - like the format of the file you see there. But what would be quite useful would be a kind of meta-tag where the one-sentence explanation of each object is - it's quite a work to copy-paste all those sentences by hand, and it isn't possibe to automatically search pd files for the right comments. What do you think it would be the best way to automatise this? I see these possibilities: - each developer (or the help-file maintainer) makes his own list of objects/explanations in a .txt file (some people done it already) - the developer (or the help-file maintainer) puts a comment in the helpfile of the object that gets grepd - is it possible to add ##-comments in the pd syntax? - in the help patch each explanation has a special string that allows grep to extract it automatically? like "[prepent]:: is a shortcut for [list prepend]--[list trim]" instead of "[prepent] is a shortcut for [list prepend]--[list trim]" (string was ::) this one could be the most effective, but I don't like it because it makes all developers use the same format. - HC suggested to take the info from the pdpedia - which would make sure that pdpedia stays more actualized. I guess that's what you did, but I don't know how to do it.
One other thing are the object categories: they worked good for pd-van, but in pd-ext there are too many objects, so more categories would be necessary: lists, filters~, generators~, etc. I would propose to increase the number of categories, but that should be talked in the community (and have the blessing of the pope).
João Pais wrote:
(maybe this is of general interest for pd users?) speaking of lists, I once did a similar thing some years ago, collecting 2682 objects. the list is far away from being complete or up to date... http://www.parasitaere-kapazitaeten.net/files/GENERAL_ALL.csv_.txt
I already made my one available several times on the list - whenever the question "how many objects are in pd-ext" comes -, but probably it wasn't that popular. 2682 objects? when I check the properties of the extra folder (windows), I get 2666 files - bear in mind that there are several repeatitions (many objects are repeated in flatspace), and other files aren just secondary material, and some objects don't work. did you sort out repetitions or something?
how did you extract this list?
I did this manually, a lot of copy and paste. and yes, there might be some duplicates and some unusual objects like all the gemgl objects are in the list... marius.
I already made my one available several times on the list - whenever the question "how many objects are in pd-ext" comes -, but probably it wasn't that popular. 2682 objects? when I check the properties of the extra folder (windows), I get 2666 files - bear in mind that there are several repeatitions (many objects are repeated in flatspace), and other files aren just secondary material, and some objects don't work. did you sort out repetitions or something? how did you extract this list?
I did this manually, a lot of copy and paste. and yes, there might be some duplicates and some unusual objects like all the gemgl objects are in the list...
ah ah, and I thought I was the only crazy guy going through object per object and extract the information (see excel file). ok, maybe we should discuss a more serious way of automatising this.
Hallo, João Pais hat gesagt: // João Pais wrote:
I already made my one available several times on the list - whenever the question "how many objects are in pd-ext" comes -, but probably it wasn't that popular. 2682 objects? when I check the properties of the extra folder (windows), I get 2666 files - bear in mind that there are several repeatitions (many objects are repeated in flatspace), and other files aren just secondary material, and some objects don't work. did you sort out repetitions or something? how did you extract this list?
I did this manually, a lot of copy and paste. and yes, there might be some duplicates and some unusual objects like all the gemgl objects are in the list...
ah ah, and I thought I was the only crazy guy going through object per object and extract the information (see excel file). ok, maybe we should discuss a more serious way of automatising this.
I've just added the system we use in the RjDj lib to [list]-abs as well. It's pretty simple, but cool: All objects are described in a textfile using this format:
objectname - short object description in one line without commas
In [list]-abs this file is called "list-abs-intro.txt". (It also allows lines consisting of just an integer number, which is used to optionally make room for larger GUI objects in the overview patch.)
A helper file reads this list into a textfile and dynamically patches all referenced objects and descriptions into a subpatch. This patch is called "list-abs-intro.pd".
Ciao
I've just added the system we use in the RjDj lib to [list]-abs as well. It's pretty simple, but cool: All objects are described in a textfile using this format:
objectname - short object description in one line without commas
In [list]-abs this file is called "list-abs-intro.txt". (It also allows lines consisting of just an integer number, which is used to optionally make room for larger GUI objects in the overview patch.)
A helper file reads this list into a textfile and dynamically patches all referenced objects and descriptions into a subpatch. This patch is called "list-abs-intro.pd".
I think that it would be the best idea as well - many libraries already bring their object description - that's pd's "official" format as well, as used in the old 0.INTRO.txt file. would it be possible to make that libs don't get compiled/added to the package if that list is missing? or desirable?
On Feb 27, 2009, at 2:16 AM, Frank Barknecht wrote:
Hallo, João Pais hat gesagt: // João Pais wrote:
I already made my one available several times on the list - whenever the question "how many objects are in pd-ext" comes -, but probably it wasn't that popular. 2682 objects? when I check the properties of the extra folder (windows), I get 2666 files - bear in mind that there are several repeatitions (many objects are repeated in flatspace), and other files aren just secondary material, and some objects don't work. did you sort out repetitions or something? how did you extract this list?
I did this manually, a lot of copy and paste. and yes, there might be some duplicates and some unusual objects like all the gemgl objects are in the list...
ah ah, and I thought I was the only crazy guy going through object per object and extract the information (see excel file). ok, maybe we should discuss a more serious way of automatising this.
I've just added the system we use in the RjDj lib to [list]-abs as well. It's pretty simple, but cool: All objects are described in a textfile using this format:
objectname - short object description in one line without commas
In [list]-abs this file is called "list-abs-intro.txt". (It also allows lines consisting of just an integer number, which is used to optionally make room for larger GUI objects in the overview patch.)
A helper file reads this list into a textfile and dynamically patches all referenced objects and descriptions into a subpatch. This patch is called "list-abs-intro.pd".
Sounds like a useful thing. How about sticking this info into a subpatch in the help patch? They could easily be parsed with textfile and route. Then there is only one file per object to maintain.
.hc
----------------------------------------------------------------------------
"Free software means you control what your computer does. Non-free software means someone else controls that, and to some extent controls you." - Richard M. Stallman
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Sounds like a useful thing. How about sticking this info into a subpatch in the help patch? They could easily be parsed with textfile and route. Then there is only one file per object to maintain.
The [pd META] approach, yes. But there is no vanilla way to get a directory listing.
Ciao
On Feb 28, 2009, at 2:22 AM, Frank Barknecht wrote:
Hallo, Hans-Christoph Steiner hat gesagt: // Hans-Christoph Steiner wrote:
Sounds like a useful thing. How about sticking this info into a subpatch in the help patch? They could easily be parsed with textfile and route. Then there is only one file per object to maintain.
The [pd META] approach, yes. But there is no vanilla way to get a directory listing.
I think Miller uses grep, does that count as vanilla? ;) On Mac OS X, the spotlight searching stuff would bring up the patches based on keyword. It would be great to have the GNOME searching stuff work on Pd help patches too, it might already. I guess the Windows file system indexing would work the same way.
.hc
Ciao
Frank Barknecht Do You RjDj.me? _ ______footils.org__
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
----------------------------------------------------------------------------
Man has survived hitherto because he was too ignorant to know how to realize his wishes. Now that he can realize them, he must either change them, or perish. -William Carlos Williams
-
Frank Barknecht -
Hans-Christoph Steiner -
João Pais -
marius schebella