When using a relative path with the new [file], it is resolved relative to Pd's start location and not relative to the patch.
Actually, it's resolved to the current working directy. This is expected behavior. The [file] interface itself is just a thin wrapper over the POSIX file API and therefore agnostic of Pd's search paths.
As Antoine has already mentioned, use [file which] if you want to resolve a relative path to the canvas environment.
Christof
On 07.01.2022 17:34, Roman Haefeli wrote:
Dear list
When using a relative path with the new [file], it is resolved relative to Pd's start location and not relative to the patch. This is unusual, as [text], [array], [table], [soundfile], etc. resolve relative paths relative to the patch. Also, I don't quite see the use case for relative to Pd's start. At least, _I_ never cared about where Pd was started from and when working on a patch meant to run on other people's computer I don't make any assumptions about Pd's start location. To me, relative to Pd's start location is pretty useless.
Now, it's really unlucky I spotted this only now after 0.52 has been released. Fixing it would break backwards-compatibility. OTOH, the fact this hasn't been reported yet makes me assume [file] with relative paths wasn't used that much yet. If this is going to be fixed, it should be fixed rather soon.
Best, Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list