[PD-dev] file search path proposal

IOhannes m zmoelnig zmoelnig at iem.at
Thu Nov 8 15:23:20 CET 2018


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?

see also https://github.com/pure-data/pure-data/issues/234
(and https://github.com/pure-data/pure-data/issues/502)

fgmasdr
IOhannes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20181108/37427552/attachment.sig>


More information about the Pd-dev mailing list