it's an abstraction that contains [readsf~], so I'm sending it an open message with the name of the sound file, hoping it finds from the declared paths.
so, I'm using [declare -path ../] to load the path relative to the patch's path.
that is "/Users/porres/Desktop/pdreverb/05dattorro/../" by the way, and it shows up as one of the search paths when using "verbose on".
So, when I open my abstraction, I can see the declared path as one of the places it searched until it found my abstraction.
Now, when trying to open a sound file from within that abstraction, it can't find the wave file I'm looking for, and if I check the verbose print I can also see that it didn't look for the path I had declared.
Here's a full print
tried /Users/porres/Documents/Pd/externals/else/piano.wav and failed
tried /Users/porres/Documents/Pd/externals/piano.wav and failed
tried /Users/porres/Documents/Pd/externals/cyclone/piano.wav and failed
tried /Users/porres/Documents/Pd/externals/else/piano.wav and failed
tried /Users/porres/Documents/Pd/externals/soundhack/piano.wav and failed
tried /Users/porres/Documents/Pd/sounds/piano.wav and failed
tried /Users/porres/Library/Pd/piano.wav and failed
tried /Library/Pd/piano.wav and failed
tried /Applications/Pd-0.48-0.app/Contents/Resources/Scripts/../extra/piano.wav and failed
tried /Applications/Pd-0.48-0.app/Contents/Resources/Scripts/../doc/5.reference/piano.wav and failed
Now, if I try to laod inside my abstraction a pd patch (that is, another abstraction) that's inside the declared path, it can look for it and find it there. I tried loading a file named "fm.pd", it works, and here's what I got.
tried /Users/porres/Desktop/pdreverb/05dattorro/../fm.pd and succeeded
just like that, it succeeded in the first attempt!
So, this all makes me believe that the declared paths relative to the patch are not, somehow, listed as search paths for other things like sound files, or maybe that's a problem with [readsf~]?
cheers