--- On Wed, 2/16/11, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] FLOSS book Lists chapter To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "Hans-Christoph Steiner" hans@eds.org, pd-list@iem.at Date: Wednesday, February 16, 2011, 5:28 AM On Tue, 15 Feb 2011, Jonathan Wilkes wrote:
--- On Tue, 2/15/11, Mathieu Bouchard matju@artengine.ca
wrote:
Yeah, that's nonsense. Pd-vanilla is the origin of
the
<m_pd.h> interface for making externals.
Btw-- the manual makes a distinction between
"abstractions" and "externs".
It needs to, at least a bit, because they have a different loading priority : *.pd is not sought for at the same time as *.pd_linux, for example.
I don't understand this process. I understand the order, but why, for example, does
[./sigmund~] create an instance of the sigmund~ class? (Pd version 0.43.0-extended-20110205, only tested it on winxp)
I think it's useful to people doing stuff with audio
who want to learn Pd without being surrounded by a haze of thousands of possibly useful, possibly buggy, poorly documented object classes that may or may not be usable for someone on a different machine.
If you thought Pd-Vanilla was that well documented to start with, you wouldn't be maintaining a separate set of help files.
We Appreciate Your Feedback. Please Rate Our Performance on the matju Scale:
[] Poor [] Unimpeachable
The old Pd internal docs are decent-- on the whole they contain the
information that you'd want to know about inlets, outlets, and args.
I found they lacked in the following areas:
- standard format ("I know the args are listed in one of these paragraphs,
but I can't remember which one")
- related objects (still working on that one)
- related topics/tutorials
- one-click links to other relevant docs (or the manual!)
- array name conflicts when more than one help patch is open
- errata that never seemed to get addressed
- a few missing/orphaned help patches
Looking over the externals, on the other hand, I see:
- massive lack of example patches (not to mention _clear_ examples)
- lots of missing help patches
Those two alone are the biggest problems that drag down the quality of the external help docs as a whole, but there are also:
- unexplained args, xlets
- some abandoned objects that crash Pd, help patches that freeze Pd
- prototype or expirimental objects not labeled as such
- stop gap help patches with no content
- incorrect terminology (referring to an anything as a list)
- dependence on order in which connections were made for trigger order
in example patches
- attempts to automate the creation of help patches, apparently without
opening any of them and noticing it didn't work
- EVERYTHING from the first list missing for lost of externals, too
How can those classes affect those users ? I mean, how can the collection of pd-extended classes act like a haze, when the users don't look at a list of 2000 classes ?
Well if you use Pd Vanilla and want to find an object that does something, you look for it, find it (or not), and start using it.
If you use Pd Extended you do the same thing, but then maybe the object you were using isn't in the next release because nobody is maintaining it, or you thought that object was an internal but it isn't*, or there are 5 different objects with 5 different interfaces to do the same thing surrounding you like a hall of mirrors, and you need to do some work to check out which ones are the most likely to continue to be maintained, and which ones are merely an illusion...
Also, keep in mind that currently it's hard to ask Pd Extended to show you all the externals that do the thing you want to do, and get back a meaningful answer.
- and of course you right-click to see what library it is actually in but
Pd's search party comes back with very bad news: "Sorry, ma'am, but your child never even existed..."
- "Puritan Data"?
I could be joking but I don't feel like it.
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC