On Sam, 2014-01-25 at 19:24 -0800, Miller Puckette wrote: > Are you using readsf~ to read th soundfile? Unfortunately, readsf~ > doesn't search along the canvas's path (for complicated reasons)
Do those complicated reasons make it unlikely that this is ever going to change? Not that I consider it an important issue, I'm just curious. > and so needs > to be sent an explicit path, like "../folder/a.wav", to find files outside > the patch's directory. Or if your abstractions know their relation to the main patch - for instance, if they are located in folder that is on the same level as the main patch - you just need to prepend the correct prefix to all incoming (relative!) paths - for instance '../'. > On Sat, Jan 25, 2014 at 11:05:39PM +0100, ro...@dds.nl wrote: > > > > sorry, i should be more precise about what i experience. > > > > i'm using "../folder" to load soundfiles in my patch. > > while having a [declare -path .] in the main patch. > > > > like i said in the first mail: this works when the patch is started > > up 'directly'. Because the directory of your patch is then the start directory of Pd which is always included in the search path. > > when i first start Pd and then open the patch with the menu-open > > Pd cannot find the directory. Because then Pd is started from somewhere else and [readsf~] doesn't search in your patch's directory. It would be nice if [readsf~] would respect the [declare]ation in your main patch, though. Roman _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list