[PD-dev] file search path proposal

[Dan Wilcox]

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 at lists.iem.at wrote:
> 
> From: IOhannes m zmoelnig <zmoelnig at iem.at <mailto:zmoelnig at iem.at>>
> To: pd-dev at lists.iem.at <mailto:pd-dev at lists.iem.at>
> Subject: Re: [PD-dev] file search path proposal
> Message-ID: <cc0cf677-1a8e-a2ba-fce8-001e88f194c7 at iem.at <mailto:cc0cf677-1a8e-a2ba-fce8-001e88f194c7 at 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/>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20181108/18156903/attachment-0001.html>