[PD] declare [loooooooooooong]

IOhannes m zmoelnig zmoelnig at iem.at
Thu Jul 31 09:33:41 CEST 2008

Hans-Christoph Steiner wrote:

> It seems to me that using the canvas-local and global paths for  
> everything that opens a file isn't really a good idea.  You never  
> know where a file could come from. But that is entrenched, so it is  
> not going anywhere.  

but isn't this right now?

when a files gets searched it will be searched "everywhere" (in The Path);
in Pd-vanilla (default settings), it might come from "." (wherever that 
is) or from <pd>/extra/
in Pd-extended (default settings on OSX) it will additionally search 
them in 41 other locations.

these numbers come from [soundfiler] opening a (non-existant) sound-file 
directly in the parent patch.

the example is probably a good argument against global paths, but i 
don't think adding canvas-local paths will make it worse.
the important thing is that there is a logic behind the search order 
(that is comprehendable by humans)

> Personally I think [soundfiler] should only look  
> in the current directory of the patch if it is a relative path.  If  

otoh, i do think that frank's and marius' request for abstraction-local 
paths are valid and important.

> you need to use more complicated paths, you can use [getdir].  But I  

unfortunately i don't have [getdir].
proposing an external sounds pretty ugly to me, when it comes to a 
fundamental problem. of course we could all use not Pd.

> think we should let this issue rest and just focus on the namespace  
> for loading objectclasses.

yes, i think that is what frank was trying to say: due to the missing 
definitions we keep mixing up searchpaths and namespaces - they are 
different things (only Pd happens to make them related; right, java does 
so too, but who uses java?)

anyhow, i very much like frank's idea of separating the object 
searchpath from the ressourcespath.
(but then it is nice to have them unified for special applications; e.g. 
when i want to tread a Pd-patch as data)

and btw, i always found that the entire helppath thing was a ugly and 
should be removed as soon as possible.

>> Oh, and maybe this should move to pd-dev?
> That's what this wiki page is for, let's start documenting ideas and  

well, personally i feel more inclined to follow a discussion (and 
participate in it) on push media rather than pull media.


More information about the Pd-list mailing list