--- On Mon, 8/16/10, João Pais jmmmpais@googlemail.com wrote:
From: João Pais jmmmpais@googlemail.com Subject: Re: Object List (was: Re: [PD] [FM Discuss] Portuguese translation of the PD manual) To: "Mathieu Bouchard" matju@artengine.ca, "Jonathan Wilkes" jancsika@yahoo.com Cc: pd-list@iem.at, discuss@lists.flossmanuals.net Date: Monday, August 16, 2010, 12:10 PM
Here's an object list I
dynamically created, relying on the
PDDP tags that I added to each patch.
http://puredata.info/Members/jwilkes/object-list/view
It makes use of pddp/helplink (although I'm finding that for objects
that all
share a common help patch, like [cos] and [sin],
helplink
doesn't work). It's in order of file name, so
it's not quite
alphabetical.
But rather than a big static list, I'd like to see a
nice
object search function that can generate a list
relevant to the
user. (Especially when searching for
externals.)
I'll look at it later. I guess that would be a nice system, but it needs that the developers also take their part, or allow that someone formats their patches (or makes them write one in the first place).
If the developers do their part, I think this would be a great system. But since I'm used that they don't I was thinking myself of a "dynamic" database which scans the /extra folder. Added items (based on filenames) would be formatted once, and then fixed. New items would have to be formated once by hand (copy-paste the description...), but then would remain in the library. I thought of this because several people don't follow any guidelines (which don't exist), so it's not possible to trust the developers to help with that work.
All that's really needed is one rule: new objects must have a help patch to be included in Pd-ext. Once there is a help patch you can get the name of the object from the help patch's file name, and the library from the folder it's in.
Other helpful info to be included would be the following PDDP tags: ALIAS shortname for the object AUTHOR LICENSE KEYWORDS DESCRIPTION (this is probably the most important for searching) RELEASE_DATE
and then inlet info: INLET_0 set bang float INLET_1 float INLET_N (variable number of inlets) INLET_R (rightmost inlet, like pointer inlet on [append])
and the same for outlets.
I put all this in the [pd META] subpatch, but it could easily be put in the main body of the patch.
I think matju's GFDP ends up with a lot of the same info, except for AUTHOR, LICENSE, KEYWORDS, RELEASE_DATE.
-Jonathan
But your system would be much nicer. Maybe would it be possible to make code submitabble only when there's a help patch with it, or generate these tags through svn? It's not that much work to add that to the vanilla objects, it's worth the effort of doing it once - I could help with that, if St Puckette allows it.
I've already added those tags to all the vanilla objects -- that's how I was able to generate the list dynamically. I just need to finish one or two "all_about_" patches and I'll commit everything.
I've also added tags to many of the libraries. I think cyclone and some others are finished but I'm not sure who I need to ask for permission to change these.
João
(Btw, I still didn't send you my related objects for you to add)