not sure about the startup directory, but i'm pretty sure that pd tries to resolve objects in the same directory as the current patch before opening libraries. i was using this at one time to mask the OSC objects with non-functional plug-a-like dummies to make my development environment more stable when i wasn't directly testing the OSC stuff (the objects had/have a lovely tendency to kill pd).
pix.
On Wed, 07 Nov 2001 14:13:01 +0100 Krzysztof Czaja czaja@chopin.edu.pl wrote:
hi,
I would rather defend the way it is now, i.e. to
For the time being you have two options:
(prefered) to copy the main patch into your startup directory;
to replace [<external-name>] with
[<full-path-into-startup-directory>/<external-name>]
Krzysztof
Ludde wrote:
Dear list members,
I think there is a problem with the load path of patches in PD. I have
a
situation where there is patches in a library and in the startup directory. Now I like to override some patch in the library by adding a modified version of it in the startup directory. I think this should be a
rather
good idea but PD does not handle the situation as I would like. If you try to
override
a patch that is includen in another patch in the library then PD will open the one from the library and not from the startup directory as I would like. How can you tell PD to first look in the startup
directory?
I have tried to solve the problem without success by using the -path
in
the starup command. How can this problem be solve? What do others
think
about the search order?
Best regards, Peter Lunden