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