apparent path problem in making a collective
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
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:
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.
(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!
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?
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…:
----------begin_max5_patcher---------- 426.3oc0UF0SBCCDG+4sOEMk3anYcfrM8ceSSLl3KFhoPKrZ1ZWV6TPBe2cW 2FBDj.rfI7x0r6tt6+8aW6V35fGolw0Xzcn2PNNKbcbrt.GN0O6fSoyFmP01 zvR9WpQef6VExvmYrtoizpjBCOiZhaBpJLIbiYdFup.XLZXcnxzFGKjSeOmO 1TEseT3MdcQDeBrD5AV+R6p8DKXLtDRlT6Qvr0tTOW62TzIJoQRSskD+JOmQ kzlXxhTgrTR50eIvFzhusaf.0dUtU5uJYv4RWWvzscjRmkKjlIH8bn.nqzON +khrLUt4AUBim2N5cafka85eb3qm2EC+RTTVJWqQsXTqucFafEYgQGIpHWLn xDKz11eeSUcOLXEM.rACNRXclOW5W6US+rog57DzRaz5H78foyyfkKYUdPCO ARCSdzo7S8P5s1CoQVhRBCpVNTXFDczvz+Tm7rJBmHja+2AaaA92DRZUQ93F HTegL529hw0FgjZDJ4Z4.25f1WymJXYpxaKq0ve7E6PkzVka2ZBfLhrCM4cd zD4P3j++Km72.A6VSsQRkOrz8Gfx1h+Z -----------end_max5_patcher-----------
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!
----------begin_max5_patcher---------- 499.3ocyU10aaBCEF9Z3Wgkq1cYMfIju1UM22JMosoIMUM4DNs3IvDwwzltp 9ee3iAM5FcMMEk0aLxGae766iO1buuGecwN.4rkruw77t22yiBYC30z2imK2 sIShzz3Z31h0+fOxMjA1YnvaKUZC6rksCnqxKpLYfgVUPSzqJzFT8SvFawos Q2JMaRU5q+dIrw3zR7jf5gYh41Ywhn1vYmFvtrYMpDZaqkx6i4cxtVlSYmeV oRl0QMJcqXBswdv221LZHb8pgx0SV3raj34cczQv04.hxqg+11RSZ+VNrGKG F9u7bTzLxlMdNl5LuimcY2b2Vvs.NuObLoWb7EnLQpk8BDwvUFHWiEYUFXP4 xhIDJbel6tND7h4h3EykA75AR2Othg2YYA6c3.CGgvUtDJNP5DE7+DOlTERl CJ6GLhC91zThOyltGbYzSwlCnzoIHJuoM8mbgcCdjSY7OXaN4i1VPm3hvtb. efZUVErb7mQnDGifIUVB33UprL7b4WiG+I.M0bKZnJGmFRbdZySXhC7MrYKd UOhQojmoz+4OzIEai+XRhEUkaZETyanreq4DBRRipP2YN1phNSJUkj.5t+rK Wkrsn9VeiFdhi08URz1E9LZ53JIw9PofiKkB1CMYqt5fx2Dmbwu8N4dEJpty C9+BeG0mtB -----------end_max5_patcher-----------
#include && .bios
IUHbfhieua 983r324r98 C>DKJHjhx jkH jkh
D AO:UND:Ch23′[:URJN32K LNDsajr]
iWUFP)wu9fP9UWJFP()uiwp)(ufP0(WUGYVu3wof98gyuh24 U7R0327 R2U7F0T2W u7ft yg82-8n tg=328u7y2
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.