[PD] relative pathes: problems with [open(-message to pd

Chris McCormick chris at mccormick.cx
Sat Mar 24 03:14:56 CET 2007

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.



chris at mccormick.cx

More information about the Pd-list mailing list