I'd suggest simply adding a commemnt like "tags: os midi oscillator" - then we can just "grep tags: ../5.doc/*.pd | grep -i midi" to quickly get a list of relevant patches. It would also help to work up a list of commonly used tags so new help patches can re-use existing ones where possible - for instance, either "signal" or "tilde" or "~" but not chosen at random from the three :)
cheers Miller
On Sat, Feb 28, 2009 at 03:11:31PM +0100, Frank Barknecht wrote:
Hallo, Luke Iannini hat gesagt: // Luke Iannini wrote:
I just took a look at Max/MSP and they have a nice tagging system, as well as an excellent configurable filter on their file browser that ends up being a pretty elegant solution to many of these problems. Perhaps going the route of adding parsable tags to object help patches (e.g. a comment containing ##os ##midi ##oscillator (hm, quite an odd object)) that can then be read back by the help-browser is more what you're suggesting (I got that feeling from the threads you linked Mathieu).
I think, that's a good aproach (although it doesn't solve any namespacing issues) and a start for this is already existing in the [pd META] subpatch that you can find in some help patches in the svn.
Documentation and categorization IMO should live as closely as possible to where the action is, i.e. in a help file or embedded in an abstraction/external.
BTW: That is (and already was in the discussion about it at pd~conv Montreal) my main problem with pdpedia: IMO a Pd doc wiki takes the reference documention too far away from the files. I'm pretty sure, that people will rather add a [pd META] or so to their help files than go and edit a pdpedia page. In turn, a pdpedia page can parse and read out the META data from a help file - in fact, most of the useful stuff in pdpedia has been generated that way. The success of comment-generated docs or Python's docstrings illustrate my reasoning.
Ciao
Frank
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev