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, [email protected] wrote: > > From: IOhannes m zmoelnig <[email protected] <mailto:[email protected]>> > To: [email protected] <mailto:[email protected]> > Subject: Re: [PD-dev] file search path proposal > Message-ID: <[email protected] > <mailto:[email protected]>> > 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 [email protected] https://lists.puredata.info/listinfo/pd-dev
