[PD] libraries in Pd-extended 0.43
Jonathan Wilkes
jancsika at yahoo.com
Tue Dec 14 05:25:34 CET 2010
--- On Tue, 12/14/10, Mathieu Bouchard <matju at artengine.ca> wrote:
> From: Mathieu Bouchard <matju at artengine.ca>
> Subject: Re: [PD] libraries in Pd-extended 0.43
> To: "Jonathan Wilkes" <jancsika at yahoo.com>
> Cc: "PD List" <pd-list at iem.at>, "Hans-Christoph Steiner" <hans at at.or.at>
> Date: Tuesday, December 14, 2010, 3:04 AM
> On Mon, 13 Dec 2010, Jonathan Wilkes
> wrote:
>
> > As far as improving documentation, I'd say every
> object in Pd-ext should be
> > documented clearly in a help patch that outlines:
>
> I'd say every class in Pd-ext should be
> documented clearly in a help patch that outlines:
You're right. I'm an object-o-phile. But do you find "Related
Objects" troubling-- should it be "Related Classes"?
>
> > 1) what the object does
>
> 1) what the class does
In a lot of situations you need both. For something like
canvas_class it doesn't make much sense to put all the details of
"what the class does" in one giant help file-- for instance, to
follow your GFDP model, you'd have one "see also" section that
includes [inlet] (which relates to [pd] but not to [table]) as well
as [tabread] or the "Put" menu array (vice versa). So you can have
one help patch for the class that has links to individual objects.
>
> > 5) any related objects (esp. internal objects)
>
> 5) any related classes (esp. internal classes)
Ok so you do think it should say related classes.
-Jonathan
>
>
> _______________________________________________________________________
> | Mathieu Bouchard ---- tél: +1.514.383.3801 ----
> Villeray, Montréal, QC
More information about the Pd-list
mailing list