Rodrigo Cadiz

Hi everyone. I just wrote an external for MaxMSP for OSX (Mach-0)

using flext in C++. The external reads data from a text file on disc

and then creates appropriate inlets, outlets, etc. The argument to my

Here is my question. If I type a path relative to where my Patch is,

it doesn't work. Let's say I have a patch called MyPatch.mxb that

contains my external called MyExternal. If the text file is in the

same folder as my external this doesn't work:

It works with an absolute path though, like

MyExternal /Users/myaccount/MyPatches/MyTextFile.txt

I've discovered it works from a path relative to the Max/MSP folder.

MyExternal ../../Users/myaccount/MyPatches/MyTextFile.txt

works ok because the MaxMSP program is in /Applications/MaxMSP4.5

So, it seems that for MaxMSP the current path is where the application

resides and not where the opened patches are. That's weird to me, but

BUT, there are plenty of externals and max objects that do work with a

path relative to the patch and not the application, like buffer~

You can do buffer~ mysoundfile.wav and this works if the soundfile is

in the same folder where your patch is. How is this achieved? Is the

path "reset" or converted to a path relative to the application inside

Hi everyone. I just wrote an external for MaxMSP for OSX (Mach-0)
using flext in C++. The external reads data from a text file on disc
and then creates appropriate inlets, outlets, etc. The argument to my
external is the filename path.

Here is my question. If I type a path relative to where my Patch is,
it doesn't work. Let's say I have a patch called MyPatch.mxb that
contains my external called MyExternal. If the text file is in the
same folder as my external this doesn't work:

I've discovered it works from a path relative to the Max/MSP folder.
So, something like

So, it seems that for MaxMSP the current path is where the application
resides and not where the opened patches are. That's weird to me, but
not really a problem.

BUT, there are plenty of externals and max objects that do work with a
path relative to the patch and not the application, like buffer~

You can do buffer~ mysoundfile.wav and this works if the soundfile is
in the same folder where your patch is. How is this achieved? Is the
path "reset" or converted to a path relative to the application inside
the object's code?

relative-paths-in-externals-and-objects

Max ./ paths are not relative tot the patch. They are relative to the 

application. There is no mechanism for patch relative paths at this time 

as it requires a major overhaul of the API, which won't happen until at 

least the next major release. For now, it must be accomplished by the 

user from the patcher using the thispatcher's path output.

The patcher's path is included in the search path at load, so filenames 

without a preceding "./" will owrk while loading the patch, but not 

Max ./ paths are not relative tot the patch. They are relative to the 
application. There is no mechanism for patch relative paths at this time 
as it requires a major overhaul of the API, which won't happen until at 
least the next major release. For now, it must be accomplished by the 
user from the patcher using the thispatcher's path output.

The patcher's path is included in the search path at load, so filenames 
without a preceding "./" will owrk while loading the patch, but not 
necessarily after the patch has loaded.

But, then, how is that buffer~ works even after the patch has loaded?

On Mar 21, 2006, at 3:20 PM, Rodrigo Cadiz wrote:

> But, then, how is that buffer~ works even after the patch has loaded?

It doesn't necessarily. It will only work as long as you don't change 

the current default folder (e.g. opening a fileopen dialog and 

choosing file from another folder), or open another patcher in a 

Note that you need to use locatefile_extended() to get the path of 

Btw, if you need more assistance with using the max provided API for 

finding and opening files, it's probably better suited for the 

It doesn't necessarily. It will only work as long as you don't change  
the current default folder (e.g. opening a fileopen dialog and  
choosing file from another folder), or open another patcher in a  
different folder.

Note that you need to use locatefile_extended() to get the path of  
files specified by name alone.

Btw, if you need more assistance with using the max provided API for  
finding and opening files, it's probably better suited for the  
developer's forum/mailing list.

You could try something like this in your object_new() function:

path_topathname(x->defaultPathID, NULL, tmpStr);

path_nameconform(tmpStr, x->defaultPathname, PATH_STYLE_NATIVE,

x->defaultPathname will contain the absolute pathname of

the patch that contains your object. With some string manipulation, you can form the absolute pathname to the file. 

Or, you could use chdir() (or _chdir() on win) right before you open the file. As long as your patches are outside of Max's search path, it should work. If you place your patches in Max's search path, then this method will only work if it's located in one of the

topmost directories (such as the MaxMSP application folder).

x->defaultPathID = path_getdefault();
path_topathname(x->defaultPathID, NULL, tmpStr);
path_nameconform(tmpStr, x->defaultPathname, PATH_STYLE_NATIVE,
                 PATH_TYPE_ABSOLUTE);

x->defaultPathname will contain the absolute pathname of
the patch that contains your object.  With some string manipulation, you can form the absolute pathname to the file.  
Or, you could use chdir() (or _chdir() on win) right before you open the file.  As long as your patches are outside of Max's search path, it should work.  If you place your patches in Max's search path, then this method will only work if it's located in one of the
topmost directories (such as the MaxMSP application folder).

> x->defaultPathname will contain the absolute pathname of

Woops. I mean the absolute pathname of the directory that

contains the patch that contains your object.

> x->defaultPathname will contain the absolute pathname of
> the patch that contains your object. 

Woops.  I mean the absolute pathname of the directory that
contains the patch that contains your object.


Relative paths in externals and objects