People, were you ever able to use [declare] to load paths relative to the patch and then load things like sound files? I cannot seem to do this, see my newly opened issue.
https://github.com/pure-data/pure-data/issues/234
thanks
On 10/14/2017 06:55 PM, Alexandre Torres Porres wrote:
People, were you ever able to use [declare] to load paths relative to the patch and then load things like sound files? I cannot seem to do this, see my newly opened issue.
whether the search path is used for opening data files, depends on the actual object. so which object are you using to open soundfiles?
fgmadsr IOhannes
I'd suggest turning on "verbose" andwatching it search for the file. When you use relative names for files loaded from abstractions, the "relativity" can be from where the abstraction is found, or from the calling patch, depending on where the declare object is. It can get very confusing!
cheers Miller
On Sat, Oct 14, 2017 at 06:59:58PM +0200, IOhannes m zmölnig wrote:
On 10/14/2017 06:55 PM, Alexandre Torres Porres wrote:
People, were you ever able to use [declare] to load paths relative to the patch and then load things like sound files? I cannot seem to do this, see my newly opened issue.
whether the search path is used for opening data files, depends on the actual object. so which object are you using to open soundfiles?
fgmadsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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
2017-10-14 14:10 GMT-03:00 Miller Puckette msp@ucsd.edu:
I'd suggest turning on "verbose" andwatching it search for the file. When you use relative names for files loaded from abstractions, the "relativity" can be from where the abstraction is found, or from the calling patch, depending on where the declare object is. It can get very confusing!
cheers Miller
On Sat, Oct 14, 2017 at 06:59:58PM +0200, IOhannes m zmölnig wrote:
On 10/14/2017 06:55 PM, Alexandre Torres Porres wrote:
People, were you ever able to use [declare] to load paths relative to
the
patch and then load things like sound files? I cannot seem to do this,
see
my newly opened issue.
whether the search path is used for opening data files, depends on the actual object. so which object are you using to open soundfiles?
fgmadsr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/
listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
2017-10-14 13:59 GMT-03:00 IOhannes m zmölnig zmoelnig@iem.at:
whether the search path is used for opening data files, depends on the actual object. so which object are you using to open soundfiles?
ok, I see now, seems this is probably a bug within readsf~ then!
2017-10-14 14:33 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
ok, I see now, seems this is probably a bug within readsf~ then!
yes, I confirmed this!
if I'm using [soundfiler] instead of [readsf~], it works! so... the issue actually concerns [readsf~] not looking for search paths that [declare] defined, I'll change the title of the issue I opened and edit the first message there.
Well, that seems to be a nice feature for Pd Vanilla, I hope this gets fixed soon!
cheers
-
Alexandre Torres Porres -
IOhannes m zmölnig -
Miller Puckette