[PD] Patch load path

Miller Puckette mpuckett at man104-1.ucsd.edu
Thu Nov 8 17:17:49 CET 2001


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
> >>
> 
> 



More information about the Pd-list mailing list