On Wed, 16 Feb 2011, Jonathan Wilkes wrote:
I don't understand this process. I understand the order, but why, for example, does [./sigmund~] create an instance of the sigmund~ class?
It's not like shell commands : even relative names that contain slashes are looked for in the -path. In that sense, it's more like gcc's -I options (including C_INCLUDE_PATH, CPLUS_INCLUDE_PATH and the implicit /usr/include and stuff).
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.
But I mean, if you look at Miller's index while in Pd-extended, you only see the list of the classes that are in Vanilla. It's not like the 2345 other classes are actively bugging you in this context. It's a completely different game than going in the "5.reference" folder. You don't need to install Vanilla to benefit from Miller's help files.
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.
You mean you can ask it...? (you mean 43 ?)
- 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..."
Which error message do you actually mean ?
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC