Forums > MaxMSP

apparent path problem in making a collective

Jul 17 2008 | 7:11 pm

Hi List,

I have a simple patch: you click on a ubutton and it sends a message to Max to open an html file called "troubleshooting.html". This opens a browser window just as you might expect in the TestIt2.maxpat patcher. If I then make this into a collective using the script

open thispatcher
folder Blue:/Users/sethares/BillsMaX5/Testing2

then it makes a collective called TestIt2.mxf
The folder Testing2 contains the relevant .html files and so I have included it in the build. The file troubleshooting.html does appear in the list of files that appear in the Max window.

However, if I now open TestIt2.mxf in Max runtime, it does not open the browser and the max window gives an error that

Max can not locate troubleshooting.html
Please make sure that the .html object reference
is in the Max search path

I’m unsure what I’m doing wrong… are there other commands for the script? Is there a special way to set the path for the runtime? Any help is greatly appreciated…

The patch and associated files are attached and the .mxf is here, in case it helps:

Jul 18 2008 | 3:34 pm

I notice that several people have looked at this, and some even downloaded my patcher… but I guess the root of the problem remains a mystery…

I am trying to think of other things to test to narrow down where the problem lies, so I tried building a new collective using this script that explicitly includes each and every file.

open thispatcher
include Blue:/Users/sethares/BillsMaX5/Testing2/style.css
include Blue:/Users/sethares/BillsMaX5/Testing2/top.png
include Blue:/Users/sethares/BillsMaX5/Testing2/troubleshooting.html

(I was hoping that maybe the "include folder" command was malfunctioning.) But this one also fails to function in max runtime — with the same error message:

Max could not locate troubleshooting.html

So it is appearing to me as if the process of making collectives using the "include files" or "include folders" feature is broken! Or is it possible that there is something idiosyncratic about my patch?

Any help would be much appreciated!


Jul 18 2008 | 4:33 pm

Due to the way that the web browser libraries on each OS handle file reading directly, there is currently no way to include files opened by browsers in a collective. You’ll have to leave them as separate files. The error message could be better I suppose.

David Z.

Jul 18 2008 | 9:32 pm

Thanks David, that certainly explains why this is happening.

But I’m not sure I understand the solution. Is there a way to reference external files/folders from within a collective? The documentation is pretty clear on how to do that for a standalone (by placing things in the support folder), but I don’t see how to do something similar for collectives. Perhaps there is a way to use relative paths (so that I could place the html files in a folder that’s "near" the .mxf collective)? Or does this mean that I need to make a standalone rather than a collective?

Thanks again!


Jul 20 2008 | 10:35 am

Bill Sethares schrieb:
> but I don’t see how to do something similar for collectives. Perhaps
> there is a way to use relative paths (so that I could place the html
> files in a folder that’s "near" the .mxf collective)?

I’ve done this with the help of the path message to thispatcher, if you
have a folder with all the files in it called MySupportFolder, this
should get you going to set absolute paths to the folder…:


— Pasted Max Patch, click to expand. —

Stefan Tiedje————x——-
–(_|_ —-|—–|—–()——-
— _|_)—-|—–()————–

Jul 20 2008 | 3:27 pm

Hi Stefan — thanks for looking at this — your patch is very cool because it essentially allows construction of a path name that’s relative to the location of thispatcher… It works as intended when using the .maxpat in Max proper. But if you build a collective from it, then it ceases to report the correct paths when operating from Max runtime.

To see this, I added a couple of print statements. When using runtime, thispatcher always seems to report "/" as the current path, and so the absolutepath box then reports "HD name" followed by a slash. It does this irrespective of where the .mxf is located (for instance, it gives the same wrong location when launched from the desktop as when launched from inside the max path).

Here’s the .maxpat I used (yours with a couple of print statements) and I’ve attached the .mxf that appears to malfunction when opened in runtime. It’s kind of bewildering that max proper and the runtime versions operate so differently!


— Pasted Max Patch, click to expand. —
Sep 23 2008 | 9:51 am

#include && .bios
#%% servlet

IUHbfhieua 983r324r98 C>DKJHjhx jkH jkh
D AO:UND:Ch23′[:URJN32K LNDsajr]
ufynhuYGV83Wugvux3dwy0fgdxw2eI8U F-2gfhe
hGVgvuw)"jn*YUV -9uyfVYHW*Iuy)whW

iWUFP)wu9fP9UWJFP()uiwp)(ufP0(WUGYVu3wof98gyuh24 U7R0327 R2U7F0T2W u7ft yg82-8n tg=328u7y2
r3_UJNCrf UFGI83

Though a bit esoteric for our application, in this case the
patch fuctions. However, as we all know very well, the .MXR must be implemented BEFORE the device driver is instantiated and unfortuately that can get a bit hairy.

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

Forums > MaxMSP