Relative paths in externals and objects

    Rodrigo Cadiz
    Mar 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
    • Joshua Kit Clayton
      Mar 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
    • Rodrigo Cadiz
      Mar 21 2006 | 11:20 pm
      But, then, how is that buffer~ works even after the patch has loaded?
      Rodrigo
    • Joshua Kit Clayton
      Mar 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
    • Davis Pyon
      Mar 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
    • Davis Pyon
      Mar 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.