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