[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