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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
