[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