From: Patrice Colet colet.patrice@free.fr To: pd-list pd-list@iem.at Cc: Jonathan Wilkes jancsika@yahoo.com Sent: Sunday, September 30, 2012 9:06 PM Subject: Re: [PD] namespaces in help files [was: Re: [pd] osc processing array to the pd table]
De: "Jonathan Wilkes" jancsika@yahoo.com
I use to remove all the stuff at startup and use this namespace/ stuff, or even better, the [declare] thingy in main patches, then it's easier to figure out what's happening.
It would be cool to have this in help files,
That shouldn't be necessary if the author uses the libdir format because the binaries are in the same directory as the help files and Pd looks there first for the objects.
Unfortunately that same behavior doesn't apply for abstractions but it should.
Hi Jonathan, and thanks for answering,
most of the nice pdx stuff isn't in libdir format, like iem and Gem,
I opened up iemlib and iemmatrix in the browser of Pd-extended 0.43 and it looks like the binaries are in the same dir as the help patches. Are there some iem* libs that aren't like this?
the last isn't so hard to fix, it's a just a single word to put in startup file, but the first is full of helpfiles where many different objects from different libs couldn't be created, some even crashes pd (win32 still, 20120720 version).
Did you file a bug report for the crashes?
As for help patches using objects from different libs-- they should probably add [import] for those objects, or better yet use Vanilla objects instead. (But I know that can't be done for everything-- some help patches use stuff like [grid] for an example patch.)
Also the main problem isn't really about figuring out what's happening in patches, but something that has been often debated in the list, conflictual objects, same name but different behaviors, like [counter] for example, is this has been solved after all?
I'm not sure of the current status of this problem or the road map to fixing it.
-Jonathan