monohusche

I just realized that Max runtime doesn't have the option to configure file preferences. My patch (distributed as zip) uses a hierarchical file structure, and it seems as if the patchers in the sub dirs are not found.

Does that mean, the only way to run this is to put the app into the Max5 directory, or is there a secret way to tell Runtime where to look for files ?

file-preferences-in-runtime-2

If you make a collective, and not a standalone, then this issue occurs. There is a way to tell a patch were it sits with the thispatcher object. (Although I think to remember that this actually does not work in a collective; search the forum.) From there you can point to specific folders. Does this mean you want to be dynamically loading subpatches? Of course in a standalone there's not such an issue.

not completely sure about the terms "collective" vs. "standalone".

I reckon "Collective" refers to an mxf file compiled with Max to contain all necessary files. At the moment,I am not using that as there are some files within the distribution which end users will need access to (in order to customize). Obviously, not possible to get to the inner workings of an mxf.

What do you exactly mean by "standalone" ?

Basically, what I am referring to is a simple plain zip archive which has some sub folders in it. When starting the main patch out of the zip file, the helper patches in the sub directories are not found, and one can't tweak the file prefs of Runtime to look in the subdirs too.

Of course, there is always the option of providing a flat archive (no subdirs), and eventually, I might go back to mxf.

not completely sure about the terms "collective" vs. "standalone". 

Of course, there is always the option of providing a flat archive (no subdirs), and eventually, I might go back to mxf.


A collective is everything bundled in a single item (indeed mxf), a standalone is that thing combined with the runtime version and has the appearance of an app.

If you're using patches, then what I suggested with the thispatcheer might work. But if the folders contain patches that need to be loaded; I don't know if this is going to work. Take a look at the filepath object as well.

jvkr wrote on Fri, 27 February 2009 09:53

You can temporary add a path in the search path using [filepath] with the 0 option.

jvkr wrote on Fri, 27 February 2009 09:53If you're using patches, then what I suggested with the thispatcheer might work. But if the folders contain patches that need to be loaded; I don't know if this is going to work. Take a look at the filepath object as well.

As you said, although thispatcher can tell me the specific location of the mainpatch, loading of subpatchers is handled transparently by Max itself, and I don't think, one can influence the load process. Just to add, no dynamic subpatcher loading, just normal object instantiation.

I tried the same thing with my Max full version, removing the recursive flag on my patch dir, and the sub dir patchers weren't loaded anymore.

The problem with mxf is that firstly, one can't open it (get to the sources), and secondly, it is harder to do a cross platform distribution. One has to provide 3rd party externals for Mac and PC. But then again, that's the same as with patchers

I did try the filepath option, doesn't work as obviously the patcher hierarchy is created before the loadbangs are executed.

Means I get the "no such object" messages before the search path has been adjusted properly.

For dynamic loading probably fine, otherwise not.

As I said in another thread, I can't use mxf as there is no low level control over the included files, and it seems I can't use multi-level zip archives as Runtime doesn't support recursive searches and/or file prefs.

The only way would be to distribute as a flat archive or potentially drop the app into the Max app dir (not sure whether there is default recursion)...

monohusche wrote on Fri, 27 February 2009 11:45

I know it's not a very elegant technique, but you could use [filepath] in your main patch to set the search path, and afterwards use [pcontrol] to load the "real" patch. The problem is that you don't know when [filepath] is done, and it can take a while.

monohusche wrote on Fri, 27 February 2009 11:45I did try the filepath option, doesn't work as obviously the patcher hierarchy is created before the loadbangs are executed.

I know it's not a very elegant technique, but you could use [filepath] in your main patch to set the search path, and afterwards use [pcontrol] to load the "real" patch. The problem is that you don't know when [filepath] is done, and it can take a while.


By the way, the "clear" or "clear 4" (for instance) message to a [filepath search] object doesn't seem to clear a search path in the file preferences.

Also, dealing with this filepath object often seems to crash Max.

By the way, the "clear" or "clear 4" (for instance) message to a [filepath search] object doesn't seem to clear a search path in the file preferences.
Also, dealing with this filepath object often seems to crash Max.
Any issues?
Thanks
Zoe
Max 5.0.6 on a MBkPro 2.4GHz OSX.5.6


file preferences in runtime