jake rodriguez

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

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


4-6-standalone-search-path-is-not-set-correctly

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?

This is new and documented behaviour, changed since the 4.6 beta. 

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.

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

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:

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?  

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

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. 

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?

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.

well this is the issue, then: in my built standalones, nested subfolders of the folder containing the application are all being searched. i can build the below standalone with all 4 variations of "Search for files..." and "Utilize Search Path..." ON and/or OFF, and when running the app and clicking the ';max paths' message box, the status window reports the search path containing all the nested subfolders of the folder containing the application, including the application bundle. The only difference being that the Cyling74 folder is added to the path when "Utilize Search Path..." is checked on.

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

Path: /Applications/pathtest.app/Contents/MacOS/pathtest

Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

0 ...m.Max.pathtest.appRuntime46     0x000a6db8 sysfile_write + 12 (sysfile.c:221)

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     0x00019284 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     0x00022508 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

well  this is the issue, then:  in my built standalones, nested subfolders of the folder containing the application are all being searched.  i can build the below standalone with all 4 variations of "Search for files..." and "Utilize Search Path..." ON and/or OFF, and when running the app and clicking the ';max paths' message box, the status window reports the search path containing all the nested subfolders of the folder containing the application, including the application bundle.  The only difference being that the Cyling74 folder is added to the path when "Utilize Search Path..." is checked on.

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

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]

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
0   ...m.Max.pathtest.appRuntime46 	0x000a6db8 sysfile_write + 12 (sysfile.c:221)
1   <> 	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 	0x00019284 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 	0x00022508 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.

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

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.

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.

all jars and classes could be in MyApp.app/classes/

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.

max.jar needs to be in MyApp.app/Contents/MacOS/
other jars and classes need to be in MyApp.app/Contents/classes/

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:

>all jars and classes could be in MyApp.app/classes/

>max.jar needs to be in MyApp.app/Contents/MacOS/

>other jars and classes need to be in MyApp.app/Contents/classes/

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

202 Hack / PC-1600 User / VSTi Host / OMS Convert / Jack OS X

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/

MyApp.app/Contents/support/java/lib/max.jar (and any other .jars)
MyApp.app/Contents/support/java/classes/MyClass.class (all my classes here)

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
http://www.jackosx.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.

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.

Right ... When the 4.6b11 placement proved wrong, I just figured I'd put things where the error message suggested. 

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.

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.

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: couldn't load preferred audiodriver CoreAudio

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?
----------------------------------------------------

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

btw--this is now fixed for my purposes in 4.6.1. thanks for the prompt update!

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.

4.6: Standalone search path is not set correctly