Opening Standalone in 64 Bit as default
Mar 15 2017 | 1:18 pm
Hello, how can I set up that my standalone will open in 64 bit as a default? I am distributing a standalone and would like that the users don't have to set this up themselves.
- Mar 15 2017 | 3:40 pmYou could remove 32 bit code from Your app. open terminal and write : ditto --arch x86_64 (path to the original app) (path to new 64 bit only app) Example :ditto --arch x86_64 /Users/MaxMsp/Desktop/MyApp.app /Users/MaxMsp/Desktop/64bit/MyApp.app You can drag original app into terminal window to get the path Create new folder next to it in the finder and add that to the path as shown above There are also some apps that can do that for You, xslimmer ot similar
- Jun 16 2017 | 4:38 pmWow, way too late that I see this. Thanks for the answer (again), nonetheless, I can't get it to work. I tried it via the terminal, this is the result:ditto: No destination Usage: ditto [ <options> ] src [ ... src ] dstorditto: can't get arch info for 'x86_64/Users/Sjoerd/ "...What am I missing here?
- Jun 16 2017 | 6:49 pmtyping problem, I guess.from errors above I'd say You miss one space between x86_64 and the path.So make sure to add on space after typing ditto --arch x86_64 , before droppingthe app to the terminal window.Same applies for destination path.
- Jun 17 2017 | 7:47 pmAh yes, it worked better this time.Only it is a folder now with the contents of my app, not the fancy app Icon where I have to double-click to open.What is the next step?
- Jun 17 2017 | 8:00 pmNext step is to relax and read and understand exactly what this sentence means.You tell ditto to copy your application from one location to another, keeping only 64 bit resources.So if You tell ditto to copy the app without naming destination properly,then it will copy all from app to whatever destination You tell it.Please read my initial post carefully.
- Jun 18 2017 | 7:33 amIt worked.I created a folder with the app in it, not the app itself, then it worked properly as expected. I can still switch on open in 32 bit, but that is irrelevant since it will always open in 64 bit.Thanks man
- Jun 18 2017 | 7:01 pmIn the info.plist inside of app contents, You can find LSArchitecturePriority string.You can remove i386 string, that should remove 32 bitoption in info window.
- Jun 19 2017 | 9:25 amAwesome, both are working great! Thank you so much for your patience and sharing.
- Nov 02 2017 | 7:05 pmThank you, thank you, thank you Source Audio. You made my day with this solution to a porblem I was facing for the past few hours.
- May 19 2019 | 2:12 pmI'm attempting to follow Source Audio's instructions here, but it seems when I create the 64-bit binary it also strips out the rest of my data: when I open the resulting standalone it doesn't actually run my patch at all. Anyone have any ideas?
- May 19 2019 | 2:21 pmMaybe You are removing 32 bit code from app which actually works in 32 bit. And what exactly is "the rest of the data" Or are You maybe renaming the copy ? If Standalone is not exactly named as mxf file, than it would not auto open it.
- May 19 2019 | 2:23 pmWhat I meant is that I can create the 64-bit version binary, but when I open the resulting app it doesn't actually launch the Max patch, the application opens and nothing happens. I checked inside the package and the files are still in there (ie. the .mxf), but for some reason the 64-bit binary doesn't seem to want to execute them.EDIT: This is on Mojave, which seems to have a strange and difficult relationship with Max 7, so it could be related to that.
- May 19 2019 | 2:32 pmcould You doubleclick the executable in App Contents/MacOS/ so that it runs via terminal ?Sometimes one get's infos on possible problems.