[PD] Fwd: absolute vs relative filepath on oggread~

[Roman Haefeli]

On Mon, 2013-02-04 at 19:58 +0100, Òscar Martínez Carmona wrote:
> hey, still having problems with that, by now I'm doing it with the
> absolute filepath... maybe the solution it'll be making the main
> applicattion finding out the f*cking path and sending the whole thing
> to pd via OSC, or maybe trying it another day!

If I am not mistaken, it hasn't been mentioned yet (though IOhannes
assumed it very early) in this thread that [oggread~ ] oddly reads
relative to Pd's start location (unlike many other classes like
[textfile] or [readsf~ ] which read relative to the patch's location).

IMHO, this makes it very difficult for a patch writer to use relative
paths as the patch doesn't have any notion of where Pd was started from.
I consider the whole idea of reading relative to Pd's start location
flawed. A similar case is the 'open patch.pd path' message to [s pd].
Also this one reads relative to Pd's start location. However,
considering that it was implemented this way, because it probably
originates from the '-open' commandline flag, where it makes sense to
use a path relative to the current working directory for loading a
patch, this one is excused.  

For you, this means if your OSC application knows where Pd was started
from, you need to make it use a path relative to that location.
Otherwise you you're left with using absolute paths. When dealing with
objects like [oggread~], I'd go for absolute paths, it's just seems
safer and saner to deal with.

(or someone fixes [oggread~ ], which I even wouldn't consider to break
backwards compatibility as the current implementation doesn't really
allow to use relativ paths in meaningful way)

Roman