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.
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.
you can patch pd to print out all classes registered with class_new and class_addcreator, something like the below, then process it with a script to divide it into libraries, but you still need to add the human-readable descriptions by hand..
--- pd-0.41-4/src/s_loader.c.orig 2008-05-13 10:09:24.000000000 +0100 +++ pd-0.41-4/src/s_loader.c 2008-05-13 10:41:55.000000000 +0100 @@ -235,8 +235,10 @@ int dspstate = canvas_suspend_dsp(); int ok = 0; loader_queue_t *q;
- if (sys_verbose) post("loader: BEGIN(%s)", classname); for(q = &loaders; q; q = q->next) if (ok = q->loader(canvas, classname)) break;
- if (sys_verbose) post("loader: END(%s)", classname); canvas_resume_dsp(dspstate); return ok; }
--- pd-0.41-4/src/m_class.c.orig 2008-05-13 10:35:13.000000000 +0100 +++ pd-0.41-4/src/m_class.c 2008-05-13 10:38:56.000000000 +0100 @@ -219,6 +219,7 @@ #if 0 post("class: %s", c->c_name->s_name); #endif
- if (sys_verbose) post("class_new(%s)", c->c_name->s_name); return (c); }
@@ -249,6 +250,7 @@ *vp = va_arg(ap, t_atomtype); } va_end(ap);
- if (sys_verbose) post("class_addcreator(%s)", s->s_name); class_addmethod(pd_objectmaker, (t_method)newmethod, s, vec[0], vec[1], vec[2], vec[3], vec[4], vec[5]); }
that's nice (I didn't tried it), but I think that it would be more useful
something that scans the /extra folder, and makes a "offline" list. the
result could be something like the old 0.INTRO.txt file. or look as well
at http://puredata.info/dev/PdLibraries, in the end (Documentation) there
are some of the efforts made so far.
about the object descriptions, so far the best choice (imo) was the
sugestion to make sure that each developer add a .txt file with the object
description, and then grep it to add to the main list.
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.you can patch pd to print out all classes registered with class_new and
class_addcreator, something like the below, then process it with a
script to divide it into libraries, but you still need to add the
human-readable descriptions by hand..--- pd-0.41-4/src/s_loader.c.orig 2008-05-13 10:09:24.000000000
+0100 +++ pd-0.41-4/src/s_loader.c 2008-05-13 10:41:55.000000000 +0100 @@ -235,8 +235,10 @@ int dspstate = canvas_suspend_dsp(); int ok = 0; loader_queue_t *q;
- if (sys_verbose) post("loader: BEGIN(%s)", classname); for(q = &loaders; q; q = q->next) if (ok = q->loader(canvas, classname)) break;
- if (sys_verbose) post("loader: END(%s)", classname); canvas_resume_dsp(dspstate); return ok; }
--- pd-0.41-4/src/m_class.c.orig 2008-05-13 10:35:13.000000000
+0100 +++ pd-0.41-4/src/m_class.c 2008-05-13 10:38:56.000000000 +0100 @@ -219,6 +219,7 @@ #if 0 post("class: %s", c->c_name->s_name); #endif
- if (sys_verbose) post("class_new(%s)", c->c_name->s_name); return (c); }
@@ -249,6 +250,7 @@ *vp = va_arg(ap, t_atomtype); } va_end(ap);
- if (sys_verbose) post("class_addcreator(%s)", s->s_name); class_addmethod(pd_objectmaker, (t_method)newmethod, s, vec[0], vec[1], vec[2], vec[3], vec[4], vec[5]); }
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
Frank Barknecht Do You RjDj.me? _ ______footils.org__
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
Frank Barknecht Do You RjDj.me? _ ______footils.org__
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
-
Claude Heiland-Allen -
Frank Barknecht -
Hans-Christoph Steiner -
João Pais -
marius schebella