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/
THere are two separate things to do - one, have the readsf~ thread cache the path (and update all the caches whenever the path changes)... and then also to figure out what the most appropriate path behavior is. Perhaps it's best to make the most permissive policy, in which relative paths are searched relative to the abstraction directory, and then again relative to each (recursive) owner's directory, in turn. It sounds like a lot of fooling around though. Another possibility would be to make a new "declare" option that adds to the path relative to the patch in which the declare object is found.
Incidentally, "-lib" is extremely confusing... should we deprecate it and replace with "-loadbinary" or something?
cheers Miller On Thu, Nov 08, 2018 at 10:10:20PM +0100, Dan Wilcox wrote:
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/
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
-
Dan Wilcox -
Miller Puckette