On Nov 8, 2018, at 5:42 PM, pd-dev-request@lists.iem.at wrote:

From: IOhannes m zmoelnig <zmoelnig@iem.at>
To: pd-dev@lists.iem.at
Subject: Re: [PD-dev] file search path proposal
Message-ID: <cc0cf677-1a8e-a2ba-fce8-001e88f194c7@iem.at>
Content-Type: text/plain; charset="utf-8"

On 07.11.18 16:30, Dan Wilcox wrote:

I again run into the issue that [readsf~] expects relative paths to it's patch. This means I have to generate a full path if it's used within an abstraction. This works, but it currently requires an external, both in vanilla and my usage of libpd in PdParty.

After the small work I did with [declare -path] search mechanism, I'm thinking of something similar for the core objects that read/write files such as [textfile], [soundfiler], [writesf~], etc:

but isn't the main problem, that [readsf~] opens the soundfile in the
reading thread (rather than the main thread), and that open_via_canvas
is not thread-safe at all?