I haven't looked into the technical details yet, only making a proposal. I'm not actually saying we use declare paths, only that the current behavior should take into account canvas parentage. Couldn't we just generate an appropriate path by walking up the canvas levels and hand it off to the readsf thread?
On Nov 8, 2018, at 5:42 PM, pd-dev-request@lists.iem.at wrote:
From: IOhannes m zmoelnig <zmoelnig@iem.at mailto:zmoelnig@iem.at> To: pd-dev@lists.iem.at mailto:pd-dev@lists.iem.at Subject: Re: [PD-dev] file search path proposal Message-ID: <cc0cf677-1a8e-a2ba-fce8-001e88f194c7@iem.at mailto: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?
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/