Sethares

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

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

Please make sure that the .html object reference

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:

http://www.cae.wisc.edu/~sethares/TestIt2.mxf

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.

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

http://www.cae.wisc.edu/~sethares/TestIt2.mxf


apparent-path-problem-in-making-a-collective

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.

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?

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

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? 

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.

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 David, that certainly explains why this is happening. 

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

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

-- 
Stefan Tiedje------------x-------
--_____-----------|--------------
--(_|_ ----|-----|-----()-------
-- _|_)----|-----()--------------
----------()--------www.ccmix.com


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!

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

apparent path problem in making a collective