On Tue, 2022-01-11 at 11:31 +0000, Pierre Alexandre Tremblay wrote:
Dear all
I am wondering if I my assumptions are wrong, or if there is a discrepancy that needs solving (or not.)
Setup: if one installs objects like our flucoma.org bundle, one might have stuff included in the help, like media files. To make a clean install, we have put all of them in a folder called media/
The behaviour I rely on for the held-files is that [soundfiler] will find, for instance, [read -resize media/mysound.wav] (see attached file)
If 'media' lies near the patch, yes. From what I understand, when given a relative path to [soundfiler] (and many other objects), it'll try all search paths, starting with the directory of the path.
First question: am I right to do so (not ethically, but in term of path resolution to installed libraries)
From what I understand: yes.
— If I am right that it should find the file (as it does), let’s continue:
Second question: should [file glob] resolve [symbol media/*.wav] ? Because it doesn’t and that makes me doubt the whole world.
I guess you missed this whole thread from a few days ago: https://lists.puredata.info/pipermail/pd-list/2022-01/130639.html
TLDR: Unlike many other file accessing objects like [soundfile], [reasf~], [textfile], etc. [file] doesn't use search paths¹. Relative paths given to it are resolved against the current working directory, which is the start location of Pd (which is your user home when starting Pd from menu).
[symbol media/*.wav(->[file glob] doesn't work unless you started Pd from the location where your patch resides.
Until there is a pure [file]-based solution, you could use [dir( - [pdcontrol] to get the directory of your patch, append '/media/*.wav' to it and feed that to [file glob].
Roman
¹ [file which] does traverse all search paths, but it doesn't work for directories or for globs.