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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
