[PD] libraries in Pd-extended 0.43

[Jonathan Wilkes]

--- 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, 4:36 PM
> On Mon, 13 Dec 2010, Jonathan Wilkes
> wrote:
> 
> > You're right. I'm an object-o-phile.  But do you
> find "Related Objects" troubling-- should it be "Related
> Classes"?
> 
> well... yes
> 
> > 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
> 
> Giant help files aren't much of a problem, but it would be
> more appropriate to introduce method-categories (as in
> Smalltalk) in order to avoid the mandatory
> quasi-alphabetical sorting.
> 
> (GF sorts them like : bang float grid symbol pointer list,
> then all other names in alphabetical order, then <any>
> at the very end.)
> 
> > 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])
> 
> The t_class structure of
> [pd]/[table]/array/abstractions/patches is especially hairy.
> If a single t_class acts like it's many classes at once, it
> may make sense to document it as several classes anyway.
> However, pd will still refer you to a single help file for
> all those cases (except abstractions).

Yeah, so currently I have links inside canvas-help.pd to 
table-help.pd, pd-help.pd, graph-help.pd, and a special note 
about "Put" menu arrays with a link to array-help.pd.   
array-help.pd is necessary to have there because triggering the 
help patch for the "Put" menu array is so obscure (I wonder if 
anyone here even knows what to click to get it.)

> 
> The way a single t_class may act like several, is if it
> contains statements such as
> 
>   if
> (binbuf_getvec(x->te_binbuf)[0]==gensym("thatone")) ...
> 
> Then it's looking up which alias has been used for the
> creation and varying the behaviour accordingly. (It could
> also be using multiple creators that store something to
> remember the same info, or have a single creator with
> multiple names, that stores its t_symbol *s in one way or
> another... I'm talking about all cases of a class acting
> like it's several)
> 
> I mean that something can be called a class
> documentation-wise even though it might not be the case
> implementation-wise. What's important, then, is to structure
> the thought so that people can get the most out of those
> things, and not to document how the code is really written.
> 
> But note that if you have a [table whatever] and a [s
> pd-whatever], you can do dynamic-patching instead of the
> [table], even though the [table] won't save the contents.
> You can try «obj 0 0 inlet» and «obj 0 20 outlet» and
> see that they really add inlets and outlets on a [table]
> object. Thus, in that manner, [inlet] and [outlet] are
> relevant to [table] objects.

That's true, but just because it's possible to do that doesn't mean 
that [inlet] and [outlet] are relevant enough to show in the help 
patch for [table], any more than showing [list] in the help patch for 
[metro].

Also, it doesn't work the other way around-- [tabread], [tabwrite], 
etc. are not relevant to [pd].

> 
> 
> _______________________________________________________________________
> | Mathieu Bouchard ---- tél: +1.514.383.3801 ----
> Villeray, Montréal, QC