Forums > MaxMSP

Relative paths in externals and objects

March 21, 2006 | 7:48 pm

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:

MyExternal MyTextFile.txt

or

MyExternal ./MyTextFile.txt

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.
So, something like

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
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?

Evidently I am missing something here.

Thanks for your help.

Rodrigo


March 21, 2006 | 8:23 pm

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.

-Joshua


March 21, 2006 | 11:20 pm

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

Rodrigo


March 21, 2006 | 11:50 pm

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
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.

-Joshua


March 22, 2006 | 2:27 am

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

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).

Davis


March 22, 2006 | 2:29 am

> 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.


Viewing 6 posts - 1 through 6 (of 6 total)