hello everyone
this problem is very old, but never solved. that is why i thought, it would be ok to post it again.
When opening patches by sending messages to pd, the path is relative to pd's startup-location. when loading other files (text-, audio-, data-files etc) the path is set relative to the location of the patch. since the patch doesn't know, where pd was started, you actually cannot use relative pathes when opening patches by messages without: a) using an external ([getdir]) b) using a separate textfile, that stores the the relative path from the patch to pd's start-location. but still, this configuration file needs to be adapted when used on another system. c) do it manually by using [openpanel]
personally i don't like that behaviour and i don't see any reason, why relative to startup location could be preferred.
in any case i can think of, this behaviour just turns things unusuable. it would be nice to have the ability to distribute patches, that open other patches by messages, which work without any additional user interaction on any system (like it is possible with other files than patches).
because of above reasons, installing netpd needs the user to set a path in a configuration file.
because of above reasons, i can't find a solution for implementing a singleton pattern in pd.
right now i see two approaches to overcome this problem:
a) integrating [getdir] in pd-vanilla.
b) an additional argument for the [open(-message to choose 'relativity' between start-up or patch. i don't know the internals of pd, so i am not sure, if this is possibe at all.
don't know, if this is related: http://lists.puredata.info/pipermail/pd-list/2002-12/008989.html
or this: http://lists.puredata.info/pipermail/pd-list/2004-07/021392.html
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On 22/03/2007, at 23.41, Roman Haefeli wrote:
When opening patches by sending messages to pd, the path is
relative to pd's startup-location. when loading other files (text-, audio-, data-files etc) the path is set relative to the location of the patch. since the patch doesn't know, where pd was started, you actually
cannot use relative pathes when opening patches by messages without:
Maybe [declare] can help you? (Pd >= 0.40)
On Fri, 2007-03-23 at 10:04 +0100, Steffen wrote:
On 22/03/2007, at 23.41, Roman Haefeli wrote:
When opening patches by sending messages to pd, the path is
relative to pd's startup-location. when loading other files (text-, audio-, data-files etc) the path is set relative to the location of the patch. since the patch doesn't know, where pd was started, you actually
cannot use relative pathes when opening patches by messages without:Maybe [declare] can help you? (Pd >= 0.40)
i'm afraid, it doesn't. as i understand [declare], it lets you add pathes, so that it finds abstractions or libs. but it doesn't help, when opening a patch by message to pd.
but it's a good point to point to [declare], since it lets you decide between relative to patch and relative to pd. i'd like to have the same opportunity for the [open(-message.
actually there are three different relative paths involved in pd:
- relative to pd
- relative to patch
- relative to start-up location
i claim to deprecate the latter. i think, now everyone knows about my opinion about this topic ;-)
it would be nice to hear more voices. does anything speak _for_ 'relative to start-up location'?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Fri, Mar 23, 2007 at 11:20:01PM +0100, Roman Haefeli wrote:
On Fri, 2007-03-23 at 10:04 +0100, Steffen wrote:
On 22/03/2007, at 23.41, Roman Haefeli wrote:
When opening patches by sending messages to pd, the path is
relative to pd's startup-location. when loading other files (text-, audio-, data-files etc) the path is set relative to the location of the patch. since the patch doesn't know, where pd was started, you actually
cannot use relative pathes when opening patches by messages without:Maybe [declare] can help you? (Pd >= 0.40)
i'm afraid, it doesn't. as i understand [declare], it lets you add pathes, so that it finds abstractions or libs. but it doesn't help, when opening a patch by message to pd.
but it's a good point to point to [declare], since it lets you decide between relative to patch and relative to pd. i'd like to have the same opportunity for the [open(-message.
actually there are three different relative paths involved in pd:
- relative to pd
- relative to patch
- relative to start-up location
i claim to deprecate the latter. i think, now everyone knows about my opinion about this topic ;-)
it would be nice to hear more voices. does anything speak _for_ 'relative to start-up location'?
Yep. If I understand your meaning correctly, 'relative to start-up location' is useful in situations where you are building an application that uses Pd at it's core. You want the patches to start up correctly no matter where the user installs the entire package for Puredata+Gem+application patches. This is the case with the Ergates program I announced on this list a while ago. I'm building a windows installer for it (very slowly) and I don't think it would work without relative to start-up paths.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
On Sat, 2007-03-24 at 10:14 +0800, Chris McCormick wrote:
On Fri, Mar 23, 2007 at 11:20:01PM +0100, Roman Haefeli wrote:
On Fri, 2007-03-23 at 10:04 +0100, Steffen wrote:
On 22/03/2007, at 23.41, Roman Haefeli wrote:
When opening patches by sending messages to pd, the path is
relative to pd's startup-location. when loading other files (text-, audio-, data-files etc) the path is set relative to the location of the patch. since the patch doesn't know, where pd was started, you actually
cannot use relative pathes when opening patches by messages without:Maybe [declare] can help you? (Pd >= 0.40)
i'm afraid, it doesn't. as i understand [declare], it lets you add pathes, so that it finds abstractions or libs. but it doesn't help, when opening a patch by message to pd.
but it's a good point to point to [declare], since it lets you decide between relative to patch and relative to pd. i'd like to have the same opportunity for the [open(-message.
actually there are three different relative paths involved in pd:
- relative to pd
- relative to patch
- relative to start-up location
i claim to deprecate the latter. i think, now everyone knows about my opinion about this topic ;-)
it would be nice to hear more voices. does anything speak _for_ 'relative to start-up location'?
Yep. If I understand your meaning correctly, 'relative to start-up location' is useful in situations where you are building an application that uses Pd at it's core. You want the patches to start up correctly no matter where the user installs the entire package for Puredata+Gem+application patches. This is the case with the Ergates program I announced on this list a while ago. I'm building a windows installer for it (very slowly) and I don't think it would work without relative to start-up paths.
hm.... i think i see, what you mean. whenever a set of patches and/or externals is packed together with a startup-file (bash-script for unix, bat-file for windows), it seems to make sense to specify pathes relative to the start-up location for [open(-message. i say 'it seems', because - afaict - this 'relativity' to start-up in the [open(-message is never really used. when you open the patches directly from the script using the '-open' option, you don't need the [open(-message in pd it-self. and when you afterwards open other patches from the main-patch, you could easily open them with pathes relative to the patch. as far as i can see it, there is still no case, where you really need 'relative to start-up'. if i missed your point here, can you please elaborate a bit more, why Ergate _does_ need 'relative to start-up' for [open(-message?
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
On Sun, Mar 25, 2007 at 07:05:59PM +0200, Roman Haefeli wrote:
On Sat, 2007-03-24 at 10:14 +0800, Chris McCormick wrote:
On Fri, Mar 23, 2007 at 11:20:01PM +0100, Roman Haefeli wrote:
On Fri, 2007-03-23 at 10:04 +0100, Steffen wrote:
On 22/03/2007, at 23.41, Roman Haefeli wrote:
When opening patches by sending messages to pd, the path is
relative to pd's startup-location. when loading other files (text-, audio-,it would be nice to hear more voices. does anything speak _for_ 'relative to start-up location'?
Yep. If I understand your meaning correctly, 'relative to start-up location' is useful in situations where you are building an application that uses Pd at it's core. You want the patches to start
hm.... i think i see, what you mean. whenever a set of patches and/or externals is packed together with a startup-file (bash-script for unix, bat-file for windows), it seems to make sense to specify pathes relative to the start-up location for [open(-message. i say 'it seems', because - afaict - this 'relativity' to start-up in the [open(-message is never really used. when you open the patches directly from the script using the '-open' option, you don't need the [open(-message in pd it-self. and when you afterwards open other patches from the main-patch, you could easily open them with pathes relative to the patch. as far as i can see it, there is still no case, where you really need 'relative to start-up'. if i missed your point here, can you please elaborate a bit more, why Ergate _does_ need 'relative to start-up' for [open(-message?
Actually, I think you're correct. I think I can specify the relative paths from the .bat or .py launcher file with the -open flag and never have to have an open message inside Pd. After that, once the program is launched, I want the paths to all be relative to already loaded patches, not the launch location. I will do more testing next week when I have some spare time and let you know.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
On Fri, 23 Mar 2007 23:20:01 +0100 Roman Haefeli reduzierer@yahoo.de wrote:
i'd like to have the same opportunity for the [open(-message.
Me too.
Doesn't Pd have some kind of local special variable $cwd or something?, that would be nice way to unify all filesystem relative things.
-
Chris McCormick -
padawan12 -
Roman Haefeli -
Steffen