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
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?
i have to admit, that i do not really clearly understand what you mean: if you have an abstraction (like "abstrakt.pd") in one of your search-paths (pe path/pd/extra) and you use it in your patch, it will be loaded (aha!). if you create a (better) abstraction "abstrakt.pd" in the directory where your patch is saved (say ~home/pd/patches/), this one will be used... so where is the problem ?
if you want to change pd's behaviour, that libraries are preferred to patches (as it is now) i agree with krzysztof, that this is rather a bad idea...
anyhow, you can force a patch to be loaded (even if an external of the same name exists), by giving (sufficient parts of) its path: pe "./abs" will load an abstraction abs.pd in the current directory, although the function "abs" is built into pd
mfg.c.sdaf IOhannes
Best regards, Peter Lunden
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.
--PLu
IOhannes m zmoelnig wrote:
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?
i have to admit, that i do not really clearly understand what you mean: if you have an abstraction (like "abstrakt.pd") in one of your search-paths (pe path/pd/extra) and you use it in your patch, it will be loaded (aha!). if you create a (better) abstraction "abstrakt.pd" in the directory where your patch is saved (say ~home/pd/patches/), this one will be used... so where is the problem ?
if you want to change pd's behaviour, that libraries are preferred to patches (as it is now) i agree with krzysztof, that this is rather a bad idea...
anyhow, you can force a patch to be loaded (even if an external of the same name exists), by giving (sufficient parts of) its path: pe "./abs" will load an abstraction abs.pd in the current directory, although the function "abs" is built into pd
mfg.c.sdaf IOhannes
Best regards, Peter Lunden
perhaps you can have the users add their own "-path" statement to the pd command line which includes their own library directory.. like -path $HOME/pd/lib, and make sure it appears before the pd application directory. then have a wrapper script start this "pd application" and make sure it adds this option to the command line. or alternatively, if you are using .pdrc files you could have the user add the -path option to their ..pdrc.
i see no reason to have pd automatically do this when you can bring about the behaviour with command line options.
pix.
On Thu, 08 Nov 2001 09:14:16 +0100 Peter Lunden peter.lunden@interactiveinstitute.se 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.
--PLu
IOhannes m zmoelnig wrote:
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?
i have to admit, that i do not really clearly understand what you mean: if you have an abstraction (like "abstrakt.pd") in one of your search-paths (pe path/pd/extra) and you use it in your patch, it will
be
loaded (aha!). if you create a (better) abstraction "abstrakt.pd" in the directory where your patch is saved (say ~home/pd/patches/), this one will be used... so where is the problem ?
if you want to change pd's behaviour, that libraries are preferred to patches (as it is now) i agree with krzysztof, that this is rather a
bad
idea...
anyhow, you can force a patch to be loaded (even if an external of the same name exists), by giving (sufficient parts of) its path: pe "./abs" will load an abstraction abs.pd in the current directory, although the function "abs" is built into pd
mfg.c.sdaf IOhannes
Best regards, Peter Lunden
I agree this is confusing, but I don't see how to make it less confusing. The current model is that users wishing to copy a patch can get consistent behavior by copying the entire directory that the patch is in, and by keeping the same path as the original patch used. Moreover, a user could copy a main patch into a new directory and then _prepend the source directory to the path_ and get good behavior.
However, there's no easy way (that I can see anyway) that a user could copy and customize certain individual patches out of a directory without copying the main patch as well, or at least making a symbolic link to it. This is like the common C++ practice of subclassing... but in C++ there's always a clear hierarchy of subclasses, and in Pd there's a search path, which is a different idea entirely...
cheers Miller
On Thu, Nov 08, 2001 at 09:14:16AM +0100, 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.
--PLu
IOhannes m zmoelnig wrote:
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?
i have to admit, that i do not really clearly understand what you mean: if you have an abstraction (like "abstrakt.pd") in one of your search-paths (pe path/pd/extra) and you use it in your patch, it will be loaded (aha!). if you create a (better) abstraction "abstrakt.pd" in the directory where your patch is saved (say ~home/pd/patches/), this one will be used... so where is the problem ?
if you want to change pd's behaviour, that libraries are preferred to patches (as it is now) i agree with krzysztof, that this is rather a bad idea...
anyhow, you can force a patch to be loaded (even if an external of the same name exists), by giving (sufficient parts of) its path: pe "./abs" will load an abstraction abs.pd in the current directory, although the function "abs" is built into pd
mfg.c.sdaf IOhannes
Best regards, Peter Lunden
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 asvirtual', 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). Theuser 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.
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
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
Krzysztof Czaja wrote (and his old mouse rushed to send button): ...
I would rather defend the way it is now, i.e. to
...
... give precedence to the main patch location, and try other locations only if the abstraction/external-file has not been found there.
And yes, the next search, then, _should_ start from startup directory. The problem is, that there is no notion of a startup directory in Pd itself, but rather, it is maintaned (as `untitled_directory' variable) by the gui. Thus, once the main patch is loaded, Pd knows only of this patch's directory.
[devel] Perhaps, it would would be ok to add sys_addpath() call for pwd, before those sys_addpath() calls, that add -path paths?
Krzysztof
-
IOhannes m zmoelnig -
Krzysztof Czaja -
Ludde -
Miller Puckette -
Peter Lunden
-
pix