+ 1 mfg winfried Am Mittwoch, 7. November 2018, 16:30:56 CET schrieb Dan Wilcox: > In working with sample file paths for a project, 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: > > * absolute path: work as normal (current behavior) > * relative path starting with ./ or ../: always relative to containing patch > (current behavior) * relative path (without ./ or ../): relative to > top-level parent, ie. parent patch using an abstraction (new behavior) > > This would mean the default behavior would change to what I believe is the > *expected* behavior by most: sending a relative path to an object is > relative to whatever main patch is using the object, whether it's in an > abstraction (however many levels deep) or not. This also means projects > which use these objects on their main level would work normally. > > The only thing that might break would be using one of these objects within > an abstraction and *expecting* the path to be relative to the abstraction, > not any parent. In this case, I introduce the explicit ./ or ../ check > which forces the paths to be treated as relative to the abstraction. > > This also implicitly removes the *urgent* need for a suite of fuel path > objects, at least for me. :) > > -------- > Dan Wilcox > @danomatika <http://twitter.com/danomatika> > danomatika.com <http://danomatika.com/> > robotcowboy.com <http://robotcowboy.com/>
-- Ritsch, Winfried, Ao.Univ.Prof. Dipl.-Ing. Institut 17 Elektronische Musik und Akustik Inffeldgasse 10/III, 8010 Graz, Austria E-Mail: rit...@iem.at - http://iem.at/~ritsch - mobil ++436642439369 _______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
