4.6: Standalone search path is not set correctly
Building a standalone on max/msp 4.6, i can’t get the search paths set like they should. It seems that any combination of ‘Search for Files not in the Application’s Collective’ and ‘Utilize Search Path in Preferences File’ checked on or off results in the search path including the folder the application resides in (say, the Applications folder or Desktop or wherever the app sits), which is no good for a variety of reasons.
Build a real simple standalone to the Desktop with only the standalone object (with ‘Search for files…’ and ‘Utilize Search Path…’ both checked OFF) and a message box with ;max paths, and running the app you can see the search path includes the Desktop and all folders in the the Desktop as well as the standalone and all it’s internal folders (not just the Support folder).
i’m on a Mac PowerPC OS 10.4.7 CFM support not installed
This is new and documented behaviour, changed since the 4.6 beta.
But I was really really hoping it could be changed again to include only the application package for this release, at least as an option via standalone object or script.
In some limited beta-testing I’ve already done, users really do drag the app to the desktop and run it. So now I have to explicitly tell them not to do that (or suffer enormous startup times) in my manual or readme file. Not that anyone will read it…
Any chance of this getting changed, please C74? Please?
well i wonder if the documentation is wrong, or if i’m missing something. this is from the new 4.6 Topics pdf:
"On Mac OS X the Utilize Search Path option, when checked does the following for the search path of a standalone:
1. Adds all of the folders inside of the folder containing the application (i.e., the Contents folder and all of its subfolders)."
i believe this is the old behavior prior to 4.6 and that what has changed is that the bundle is now referenced as the ‘application’ instead of the executable inside the bundle, so shouldn’t read (i.e., the Contents folder…) anymore?
ok, but i should still be able to narrow the search path in other ways.
the manual also states:
"When Utilize Search Path is not checked, the only folder(s) added to the search path are the support folder inside the standalone application’s folder, and any of its subfolders."
but if i build a standalone with Utilize Search Path OFF, i still get the prior search path behavior, so something isn’t right.
plus, if i build a standalone with ‘Search for Files Not in the Application’s Collective’ OFF as well, I’m still getting a similarly comprehensive search path as before including the Support folder with audio and midi support contradictory to the manual as well.
so i’m confused…
jake
The documentation of this was in the 4.6b11 beta. Seems the 4.6.0 documentation is incorrect…
still, i can’t believe that this is intended behavior of the search paths. if so, it’s hugely problematic for standalone developers, as there is seemingly no way to narrow the search path of the app to only its own bundle.
for instance, i can’t even put my standalone into the Applications folder, as it ends up taking 5 minutes or more to start up and searches through all application bundles and folders including old (non-UB versions) of the standalone bundle finding old (CFM versions) of externals rendering the app broken. seems like it defeats the whole purpose of the bundle concept to have to keep it isolated in a folder in order to work properly?
This is how it is supposed to be working in the 4.6 release
For standalones, the folder containing the application is included in the search path but no subfolders of this folder (other than the application itself) are added.For the regular Max runtime, the subfolders are added as they always have been.
Yes/No?
I’ll try it now too.
-A
well
the below patch built as a standalone application in 4.6: when the built app resides in the Applications folder on my machine, will try and start up for at least 5 minutes and then crashes. crash report below. i’m sure it is because there is some other PowerPC versions of libraries or externals that are being found before the applicaton bundle is searched. is that the behavior everyone is seeing? this can’t be right…
max v2;
#N vpatcher 10 59 610 459;
#P window setfont "Sans Serif" 9.;
#P window linecount 2;
#P message 281 75 60 196617 ; max paths;
#P window linecount 1;
#N standalone;
#S creator ????;
#S statusvisible 1;
#S noloadbangdefeating 0;
#S useownplist 0;
#S preffilename pathtest;
#S overdrive 0;
#S allwindowsactive 0;
#S searchformissingfiles 0;
#S usesearchpath 0;
#S cantclosetoplevelpatchers 1;
#S audiosupport 0;
#S midisupport 0;
#P newobj 220 180 57 196617 standalone;
#P pop;
Date/Time: 2006-08-14 15:41:34.841 -0700
OS Version: 10.4.7 (Build 8J135)
Report Version: 4
Command: pathtest
Path: /Applications/pathtest.app/Contents/MacOS/pathtest
Parent: WindowServer [865]
Version: ??? (4.6)
PID: 1198
Thread: 0
Exception: EXC_BAD_ACCESS (0×0001)
Codes: KERN_PROTECTION_FAILURE (0×0002) at 0×00000000
Thread 0 Crashed:
0 …m.Max.pathtest.appRuntime46 0x000a6db8 sysfile_write + 12 (sysfile.c:221)
1 < <00000000>> 0xbfffd2c0 0 + -1073753408
2 …m.Max.pathtest.appRuntime46 0x000a7488 sysfile_spoolcopy + 112 (sysfile.c:423)
3 …m.Max.pathtest.appRuntime46 0x000ab53c xpcoll_machoload + 572 (xpcoll.c:1959)
4 …m.Max.pathtest.appRuntime46 0x000ab6b0 xpcoll_extload + 168 (xpcoll.c:1050)
5 …m.Max.pathtest.appRuntime46 0×00019284 external_load + 44 (install.c:210)
6 …m.Max.pathtest.appRuntime46 0x0001a4c8 extload + 92 (loader.c:528)
7 …m.Max.pathtest.appRuntime46 0x0001a7c0 newload_internal + 508 (loader.c:622)
8 …m.Max.pathtest.appRuntime46 0x0001a854 newload + 20 (loader.c:566)
9 …m.Max.pathtest.appRuntime46 0x00021b7c typedmess_fun + 2056 (message.c:630)
10 …m.Max.pathtest.appRuntime46 0×00022508 aeval + 964 (message.c:1062)
11 …m.Max.pathtest.appRuntime46 0x0000b788 bf_fastload + 572 (binfile.c:447)
12 …m.Max.pathtest.appRuntime46 0x000196e8 lowload_type(char*, short, long, short, atom*, short) + 460 (loader.c:145)
13 …m.Max.pathtest.appRuntime46 0x00019c78 fileload_extended + 152 (loader.c:399)
14 …m.Max.pathtest.appRuntime46 0x00019cdc fileload_type + 68 (loader.c:380)
15 …m.Max.pathtest.appRuntime46 0x000a9790 xpcoll_loadentry + 40 (xpcoll.c:798)
16 …m.Max.pathtest.appRuntime46 0x000a0738 linklist_funall + 84 (linklist.c:994)
17 …m.Max.pathtest.appRuntime46 0x000a96fc xpcoll_loadpatchers + 76 (xpcoll.c:755)
18 …m.Max.pathtest.appRuntime46 0x000a9750 xpcoll_load + 56 (xpcoll.c:571)
19 …m.Max.pathtest.appRuntime46 0x0001ba84 main + 672 (main.c:355)
20 …m.Max.pathtest.appRuntime46 0x00001f50 _start + 340 (crt.c:272)
21 …m.Max.pathtest.appRuntime46 0x00001df8 start + 60
Quote: Andrew Pask wrote on Tue, 15 August 2006 09:25
—————————————————-
> For standalones, the folder containing the application is
> included in the search path but no subfolders of this folder
> (other than the application itself) are added.
Nope.
If the app is loose in the /Applications folder, all subfolders of the /Applications folder are scanned at startup. Loooong startup times, to the point where it looks like the app has hung.
It appears that if the app is on the desktop, drives shown on the desktop are no longer scanned (as they were in 4.6b11). Good.
But aliases and folders on the desktop are scanned (try an alias to /Applications).
And aliases to network drives on the desktop will also be followed, and the drive will be mounted (and scanned?).
ok – thanks for the patch – yeah, I can reproduce.
-A
OK, so previously:
all jars and classes could be in MyApp.app/classes/
but now:
max.jar needs to be in MyApp.app/Contents/MacOS/
other jars and classes need to be in MyApp.app/Contents/classes/
Phew. So if we’re to provide a max.java.config.txt, where should that live?
Interestingly, it now seems it’s no longer possible to run the app directly from a disk image if Java is required – it needs to be copied to HD or it still won’t find the above, even if all is in the correct place. Not really ideal, users should be able to do that too if they want, immediately after download.
I still vote for the 4.6b11 behaviour…
Further … as per the disk-image problem, the standalone cannot find its Java components (error messages as above) if it is run from the root level of any (real) drive. It MUST be at least one folder deep. Weird.
At 8:17 PM +1200 8/17/06, John Pitcairn wrote:
>OK, so previously:
>
>all jars and classes could be in MyApp.app/classes/
>
>but now:
>
>max.jar needs to be in MyApp.app/Contents/MacOS/
>other jars and classes need to be in MyApp.app/Contents/classes/
John, I put my java stuff in:
MyApp.app/Contents/support/java/lib/max.jar (and any other .jars)
MyApp.app/Contents/support/java/classes/MyClass.class (all my classes here)
>Phew. So if we’re to provide a max.java.config.txt, where should that live?
I see an error message in my Status window about not being able to
locate my max.java.config.txt as well, but the default JVM options
are fine by me so I’ve not had a concern about this…
Dan
–
Dan Nigrin
Defective Records
202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X
http://www.defectiverecords.com
i’ve been just lazily dragging the full cycling74>java folder (max.java.config.txt and all) into the standalone’s Resources folder and that has been working fine with no error messages thus far. except, of course, those caused by the general search path wackiness.
Right … When the 4.6b11 placement proved wrong, I just figured I’d put things where the error message suggested.
Is the default/preferred Java classpath in standalones actually documented anywhere in the 4.6.0 docs?
I’ll experiment and see if different paths as above resolve my disk image and drive root issue.
Nope. No matter where the java folder resides, if the standalone is at root level (of a drive or disk image), it won’t find max.jar and any required classes. Move it one folder deep, and it works.
Can anyone else reproduce this?
Quote: johnpitcairn wrote on Thu, 17 August 2006 18:25
—————————————————-
> Nope. No matter where the java folder resides, if the standalone is at root level (of a drive or disk image), it won’t find max.jar and any required classes. Move it one folder deep, and it works.
>
> Can anyone else reproduce this?
—————————————————-
I can (on a MacIntel using 4.6) – after a lengthy startup time, I see in the Max window:
error: cannot build search path from root directory
(mxj) Unable to find max.jar! mxj is rendered powerless in its absence
error: unable to create JVM
error: MSP/ad: no ad folder
error: CoreAudio: No such object
error: couldn’t load preferred audiodriver CoreAudio
Dan
btw–this is now fixed for my purposes in 4.6.1. thanks for the prompt update!
jake
All standalone search path problems are fixed here too. Runs fine no matter where the app resides. Many thanks to C74.