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/
Hi, please allow me to contextualize for those who aren't really aware of issues regarding [readsf~] and the discussion on a new vanilla object that deals with "paths", I have an issue on github that relates to this: https://github.com/pure-data/pure-data/issues/502
I'm not actually sure how this issue relates to your issue, but I think that even if it is a different problem, we can have the same solution with a new object.
Em qua, 7 de nov de 2018 às 13:39, Dan Wilcox danomatika@gmail.com escreveu:
This works, but it currently requires an external, both in vanilla and my usage of libpd in PdParty.
Anyway, on to your message: what external are you using?
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. :)
Maybe we don't need a whole suit of functionalities into a new object all at once. Perhaps a solution could start with a simple object that takes care of the most urgent stuff. I think I have the same kind of issue and what I'm doing is using an external like [getdir]. The functionalties from [getdir] seem very important and should be available in Vanilla not only for this, but also for something like dynamic patching, where we want to send pd an "open" message and it requires the path as a second argument.
So then a new object that starts with only this could be good solution to your urgency, and it wouldn't break anything in any context, and it is something that will eventually need to happen as I see it.
Cheers
+ 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/
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
-
Alexandre Torres Porres -
Dan Wilcox -
IOhannes m zmoelnig -
Winfried Ritsch