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'.
when i first start Pd and then open the patch with the menu-open Pd cannot find the directory.
rolf
Are you using readsf~ to read th soundfile? Unfortunately, readsf~ doesn't search along the canvas's path (for complicated reasons) and so needs to be sent an explicit path, like "../folder/a.wav", to find files outside the patch's directory.
Alternatively you can set Pd's global path in preferences -- readsf~ knows how to use those even though it doesn't know about the patch's own declarations.
cheers Miller
On Sat, Jan 25, 2014 at 11:05:39PM +0100, rolfm@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'.
when i first start Pd and then open the patch with the menu-open Pd cannot find the directory.
rolf
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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, rolfm@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
On Sun, Jan 26, 2014 at 12:22:10PM +0100, Roman Haefeli wrote:
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.
I'd rather fix it but I want to make a bunch of path-related fixes all in one go (in particular, make abstractions and externs work reasoably so that an abstraction further down a path doesn't override an extern, and alow paths to work relaive to a calling path if one is inside an abstraction in a dfferent directory. All somehow without breaking compatibility - it's a biggish project.
cheers M
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, rolfm@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
i'm not using readsf~ but soundfiler
all my abstractions are in the same folder as the main patch
i now noticed that it does not depend on [declare ....]
[declare -path .] introduces however another complication:
Pd gives in the header of a patch-window: " name.pd - /path/of/this/patch "
the same for any used abstraction
WITH the declare the path for an abstraction in the header is
extended with "/."
[getdir] (in Pdext) follows this change.
(all this is in Windows 7 and XP)
rolf
Miller Puckette msp@ucsd.edu schreef:
Are you using readsf~ to read th soundfile? Unfortunately, readsf~ doesn't search along the canvas's path (for complicated reasons) and so needs to be sent an explicit path, like "../folder/a.wav", to find files outside the patch's directory.
Alternatively you can set Pd's global path in preferences -- readsf~ knows how to use those even though it doesn't know about the patch's own
declarations.cheers Miller
On Sat, Jan 25, 2014 at 11:05:39PM +0100, rolfm@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'.
when i first start Pd and then open the patch with the menu-open Pd cannot find the directory.
rolf
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Hi again -
I don't know nhow to reproduce this problem... can you somehow get me a patch that fails? You can just e-mail me a zip file directly if you like.
thanks Miller
On Sun, Jan 26, 2014 at 07:04:46PM +0100, rolfm@dds.nl wrote:
i'm not using readsf~ but soundfiler
all my abstractions are in the same folder as the main patch
i now noticed that it does not depend on [declare ....]
[declare -path .] introduces however another complication:
Pd gives in the header of a patch-window: " name.pd - /path/of/this/patch "
the same for any used abstraction
WITH the declare the path for an abstraction in the header is extended with "/."
[getdir] (in Pdext) follows this change.
(all this is in Windows 7 and XP)
rolf
Miller Puckette msp@ucsd.edu schreef:
Are you using readsf~ to read th soundfile? Unfortunately, readsf~ doesn't search along the canvas's path (for complicated reasons) and so needs to be sent an explicit path, like "../folder/a.wav", to find files outside the patch's directory.
Alternatively you can set Pd's global path in preferences -- readsf~ knows how to use those even though it doesn't know about the patch's own declarations.
cheers Miller
On Sat, Jan 25, 2014 at 11:05:39PM +0100, rolfm@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'.
when i first start Pd and then open the patch with the menu-open Pd cannot find the directory.
rolf
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Miller Puckette -
rolfm＠dds.nl -
Roman Haefeli