[PD] Patch load path

[Krzysztof Czaja]

hi,

in simple cases, I think, the best way is what Miller suggests: to copy
the main patch into user's directory (or create a link) and to prepend
library directory to the -path.

But unfortunately the whole problem propagates, if user wishes to replace
an abstraction, which is not directly contained in the main patch.  In
such cases user has to copy (or link to) all intermediate patches. I can
imagine, that in a complex, multiuser Pd-environment this may become
a large obstacle indeed.

Maybe one possible solution is to introduce a `virtual function'
mechanism.  What I mean here, is for a designer of library patches to
declare any overridable abstraction as `virtual', by writing, for example,
[.abs] into an object box instead of plain [abs].  Virtual resolution
would start from `user directory', and, only after failure, continue
searching in the regular order (first canvas environment, then pd_path).
The `user directory' might be set with yet another command option to pd,
or, in the absence of such, default to startup directory.

(Do not blame _me_ for using an analogy to virtual functions, please:-)

Krzysztof

Btw. there is also a nasty trick having the same effect as coping or
linking main library patch to user's directory.  It is to write, for
example

pd open ../../usr/local/pdlibdir/main.pd /home/userdir

in the sendpanel.

Peter Lunden wrote:
> 
> The problem is that I have a PD application installed on a system. The
> application consists of a library of patches. Now the directory of the
> lib is not writable by the normal users. Normaly the user starts the
> application from his own directory but the main patch is in the library.
> So the user that likes to override some behavior of the default
> application can not do this without copying a large part of the library
> to his own directory. I would perfere that the user only needs to copy
> the patches hi like to change, not half the library. It could also be
> very difficult to understand what needs to be copyed, the user has to
> understand the dependencies of the library patches. I consider this as a
> large problem.