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. mgadrt IOhannes _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
