[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