Max wrote:
Am 01.04.2009 um 15:10 schrieb IOhannes m zmoelnig:
no it's not weird. it's a known issue of Pd on OSX ("fixed" in Pd-extended, afair) where Pd get's started in the / directory. all relative paths are thus relative to the root and not to your home-directory, nor the patch-directory nor to your mailbox).
no. relative paths work fine with pix_film and others. it's a problem of pix_write.
this is still not weird. the difference between pix_film and pix_write is, that the former _reads_ a file from harddisk while the latter _writes_ one to harddisk. reading may involve searching for the file (e.g. Pd can try to evaluate your path specification in realtion to ., /, extra/, /home/max, Maildir:/inbox and http://puredata.info/; you can watch this by specifying the "-verbose" flag).
things are a bit more complicated (or simple) when you want to write a file. should Pd search for an already existing file of the specified name and overwrite it? or find the first path that does not contain a file that matches your specs? or should it try to separate your specs into a "path" and a "filename" portion and try to match the "path"? or(and should it create a directory if the path does not exist? or should it just resolve any relative specs in relation to it's working dir?
the nicest approach would probably be the one trying to match the path.
however, currently most (if not all) file-writing objects use the last mentioned approach. on osx the working-dir with Pd-vanilla (and older versions of Pd-extended) is /, with newer Pd-extended it is ${HOME}; on w32 it is (iirc) ./pd/bin (by default, but you can change this easily); on linux it is wherever you start Pd from (if you start it from the console).
fmgasdr IOhannes