App build file size?
I’m finding the size of stand alone apps created on MAX a bit prohibitive. Does anyone know any tricks for keeping them small? I’m trying to build something that is easily emailable.
Also, do apps built in Max require Runtime or is that embedded?
Oooops… never mind the last part of that question (re: Runtime). I just figured that one out myself.
The runtime engine is probably why the apps get so large. My documents tend to jump for something like 2 megs for the .maxpat, to about 50mb for the app! (this is also because of included files and the like)
However, if you’re just worried about transferring apps around on the internet, zipping them seems to work surprisingly well — my 50mb app goes down to 11mb when zipped.
Donno if that’ll help or not. For email, you might be better off using something like sendfile, or putting the app on a private section of a webserver, if you have one, and emailing a link.
It should also a clue to the first part of your question: Max standalones effectively include the Runtime. Ergo, your standalone is going to have a hard time being smaller than the Runtime.
One thing you can do is to remove any Frameworks you don’t need from your standalone. JitterAPI.framework and MaxJSRef.framework are often not needed, and they’re two of the heavier components.
But Max standalones, by their nature, are never going to be lean-n-mean apps.
Thanks for the replies guys. Totally helpful.
I guess the way to do things is to post the app online and provide links. I wanted it emailable because the project is actually a promotional thing for a movie, we thought it would be cool to have an interactive ‘invitation’.
Regarding removing frameworks – do I just simply delete those from the Package Contents?
|firstname.lastname@example.org wrote on Fri, 21 August 2009 20:36|
|Regarding removing frameworks – do I just simply delete those from the Package Contents?|
Yep. Show Package Contents on your standalone, navigate to Frameworks, and trash anything you’re sure you don’t need.
You can also take a look at the Resources/ and support/ folders, although these are far smaller. And there are some things there that may superficially appear unnecessary it will turn out you need, so make sure you understand what the various things are for and test thoroughly if you remove anything else. But it’s probably safer to leave the small stuff in place.
so if I understand correctly, making a stand alone is simply a wrapped runtime — thus nothing is compiled into anything else but a live-working Max patch?
I am asking because we were lamenting if there are any speed/CPU-efficiency gains involved by making a stand alone?
It’s more to ask of your end users, but if you tell them just to download the Runtime from Cycling, they only have to do it once. Then you can distribute your patches as .maxpat, which is small and cross-platform…no need to make separate apps for each.
One advantage to standalones–and it is an advantage of superlative value–is that they avoid numerous version issues.
Distribute a collective built with Max 4 in 2007, someone downloads it in 2009 and gets the Max 5 Runtime. No joy in Mudville.
Distribute a standalone built with Max 4 in 2007, someone downloads it in 2009; no Runtime version issues, plus you’re good for a couple of OS updates, plus you’ve got the correct versions of all the included custom externals, plus those externals play nice with the Runtime.
The standalone will probably still run in 2011 on OS 10.7 or so.
Yes, standalones are big, but they avoid a lot of headaches.
Which leads to the ultimate advice: as long you expect things to change, send collectives. As soon its done create a standalone maybe with a zipped version of the sources…