[PD] trouble with library paths

Matteo Sisti Sette matteosistisette at gmail.com
Mon Jan 31 18:02:02 CET 2011


I think there are some libraries that are not being added to the 
classpath by default in Pd-Extended, and I wonder whether there is a 
particular reason for that or if it is just a "bug" in the distribution.

Among other things, I would expect help patches to work out of the box, 
and I wouldn't expect a library to be included in Pd-Extended if it 
depends on another one which is not.

That said, the issues that I detected so far are:

- the [pix_blobtracker] abstraction doesn't create unless you write it 

However, if you open its help patch from the help broser, the object 
[pix_blobtracker] contained in it does create.

Since the Gem library is loaded by default and all Gem objects are 
available without writing the [Gem/... ] prefix, I guess it would be 
cleaner to have Gem added to the path by default so that the 
abstractions are available as well.

Or is there some reason against that?

- the [pix_blobtracker] abstraction contains some objects from iemmatrix 
which are actually included in pd Extended, but the library's path is 
not added by default. Inside pix_blobtracker, they are written without 
the path, so the way Pd-Extended is distributed (i.e. out of the box) 
they don't create and [pix_blobtracker] doesn't work.

You need either to replace [mtx_,...] with [iemmatrix/mtx_...] within 
[pix_blobtracker] or to add iemmatrix to the path.

It seems indeed that none of the iem_... libraries is included by 
default in the path. Is there a reason why they are not while most other 
libraries in pd_extended are?


More information about the Pd-list mailing list