Forums > MaxMSP

App build file size?

August 21, 2009 | 4:03 pm

Hi guys,

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?

Cheers,
Joel


August 21, 2009 | 4:05 pm

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


August 21, 2009 | 5:11 pm

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.


August 21, 2009 | 5:22 pm

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.


August 21, 2009 | 6:36 pm

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 again,
Joel


August 22, 2009 | 12:32 pm
joel@squarewave.ca 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.



k9
August 23, 2009 | 12:05 pm

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?

Kai


August 23, 2009 | 12:59 pm

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.

lh


August 25, 2009 | 10:22 am

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.


August 27, 2009 | 10:12 am

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.


August 29, 2009 | 6:14 am

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…


Viewing 11 posts - 1 through 11 (of 11 total)