joelsquare

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?

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.

app-build-file-size

Oooops... never mind the last part of that question (re: Runtime). I just figured that one out myself.

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.

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)

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?

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

joel@squarewave.ca wrote on Fri, 21 August 2009 20:36

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.

joel@squarewave.ca wrote on Fri, 21 August 2009 20:36Regarding removing frameworks - do I just simply delete those from the Package Contents?

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?

A standalone is the runtime and a collective .mxf file. If you don't wish to distribute the runtime you can build the collective and have users download the runtime from the cycling74 website, this will reduce the filesize considerably. A collective is a bundle of all the patches, externals, images, abstractions, javascripts etc that the patch needs to run. You do have to include some of these yourself in the build script. The important thing here is that an app is runtime plus collective not runtime plus maxpat. I hope this clears things up a bit for you.

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

App build file size?