[PD] libraries in Pd-extended 0.43

[Jonathan Wilkes]

--- On Sun, 12/19/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: Sunday, December 19, 2010, 1:54 AM
> On Tue, 14 Dec 2010, Jonathan Wilkes
> wrote:
> 
> > 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.)
> 
> I don't know how you can possibly not get it.

That's probably because you've never gotten it.  Clicking on the graph 
that contains the array opens up 'canvas-help.pd'.  But you can open 
a help patch named 'array-help.pd' when you:

a) right-click on the "Put" menu array and choose "Open",
b) mouse-over an array element until the arrow cursor changes directions,
c) right-click and choose help.

Then you will receive enlightenment from Pd's generous help docs:

sorry, couldn't find help patch for "array.pd"

Though it's certainly to the point, I thought a user might want a 
tad bit more information than that, so I made an array-help.pd 
patch, and linked to it in canvas-help.pd for those few boring users 
who choose not to click random spots within a patch until something 
helpful and relevant happens.

-Jonathan

> Do you expect
> that you can get it by right-clicking the array's label ?
> Because, it doesn't work for any other label (IEMGUI...),
> so, why would it work for Array's label ?
> 
> > 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].
> 
> Actually, when you have a [table], you don't have one
> object, you have two of them.

Three of them.  There's also a graph within the table.

> When you have [table foo],
> receive-symbol "pd-foo" sends to a canvas, whereas
> receive-symbol "foo" sends to the internal t_array object,
> which has all of the array-specific methods. This has to be
> made clear, because it's not like an inheritance-like
> pattern.
> 
> An inheritance-like pattern (or interface pattern) would
> be, for example, to have one single help-patch for most of
> the common methods in iemguis, those that have exactly the
> same behaviour, to emphasise that they are one single family
> (even though inheritance in pd is mostly in our
> imagination). It's a matter of documenting things in a
> non-repetitive, synthetic manner, and with a mindset that
> encourages consistency.

How do you make that system of documentation consistent across 
libraries?  (And show links across libraries?)

> 
> When you have one class that seemingly would include one
> complete other helpfile's content but not the other way
> around, that would usually be an inheritance pattern, but
> it's not here, because instead, it's mostly that a canvas
> has a t_array tacked onto it, vs not.
> 
> It can't be called delegation pattern either, because in a
> delegation pattern, you have two objects, of which you only
> send to one, which will forward the message to the other one
> whenever appropriate. This is not the case here, because you
> can send to two different receive-symbols, and you have to
> send to the correct one.
> 
> I could have said a lot less, but I just thought I'd give
> you some more doc ideas.
> 
> 
> _______________________________________________________________________
> | Mathieu Bouchard ---- tél: +1.514.383.3801 ----
> Villeray, Montréal, QC