A question about subpatchers in executables
My current project is pretty huge. It already has 56 maxpat files in the project list. Some of my patches are rather large and ungainly and I have thought about breaking more of them down into smaller units. However, I'm not sure if it would make my resulting executable bigger or smaller.
My question is whether, when building an executable file, is every instance of a maxpat file added to the mxf collectable file each time it is referenced as an object in a patch or does just one copy get used for all access points.
For example, I have a snippet object in a maxpat that generates a sysex message from various parameters fed into its multiple inputs.
If I use that snippet as an object ten times in a patcher, do ten copies of my snippet file get added to the parent subpatcher at each point of use, with ten copies of the code going into the mxf file, or does only one copy of the snippet file get accessed from all ten objects in the parent, with only one copy of the code added to the mxf?
are you talking file size? then don´t bother, those few pages of text do not matter much, 99% of an app is the runtime stuff.
I'm not sure that you realise how huge my project is! It's A LOT of text!
My 56 project files take up 4.6MB of disk space as opposed to the runtime executable of 30.46MB - that's a tad more than 1% of the total!
oh, apps became smaller again? :) in max 7 standalones were like 400 mb long, which was unusable.
100kb per patcher file is surely a lot of text, but i would not say that in 2024 this would fall under "big".
100kb are about 1,500 objectboxes and 15,000 connections. well, or a coll with some meaningful content. :)
if you want to be sure that instances of patches (or other content linked from patches) do not become copies, leaving everything as single files is the best strategy. i think for embedded audio you would only reference to one original from multiple places, but i am not so sure what happens when you build a collective or embed a bpatcher in the motherpatcher.
regarding your snippets, poly~ or script-creating patcher content will also lead to smaller files.
it is easy to find out what happens when collective gets build with subpatchers refering to abstraction.
make 1, 10 or 20 copies of subpatcher refering to abstraction, and compare builds.
I remember removing stuff from folder from where it gets built into collective just before building it, then one places abstractions or other files like pictures next to mxf file.
That way one can edit abstractions without need to rebuild again.
By the way, apps did not get smaller.
That 34 MB Andy mentions is only windows exe file.
If one does not know how to strip,
or even better avoid adding all unneeded
resources,frameworks etc, it gets even worse than max 7
My original built and encapsulated (VirtualBox) executable exceeded 100MB initially. I have become braver at eliminating a lot of the Max 8 bloatware that gets included by default and have now got it down to 60MB. I'd love to know what else I could safely get rid of but it's all trial and error at the end of the day. You delete something that you can't possibly think is necessary and suddenly the app stops working! And what are all those SVG files for?
It's a pity that there isn't a resource somewhere that lists all the resource folder contents that get added by default, what they do and whether they can be deleted or not. It would save a truckload of time!
If you mean svg files in interfaces
you can trash most of them.
I usallly only leave maxinterface,
maxcolors and few other files in there.
Make own audio status patcher if your app uses audio.
That way you can also remove java
All my project does is to do a lot of MIDI message processing. There is also a bit of OSC thrown in for good measure but that is all handled by Sadam and ODot externals.
I can't see any reference to Java in my VirtualBox resources folder.
I have no idea about your patch,
my advices only mention potential
reduction
Maybe what I could do is to delete just about everything and then add back everything that Max complains about not being able to find?
I would say that is a bit too radical,
Max would maybe not start at all
main reduction concerns extensions and frameworks
Ok, understood.
I would not use latest max
What you describe :
midi, OSC would run perfect even in max 5
If you need max 8, then 8.1.11 is best choice, unless it has dome bugs in objects and functions you use
Well that was a productive exercise. I've managed to eliminate another 16MB of bloatware from my encapsulated executable. So that's a reduction from over 100Mb down to 44MB and the encapsulation takes about 1/3 of the time to perform.
I'm well impressed!
Maybe what I could do is to delete just about everything and then add back everything that Max complains about not being able to find?
that should be how the regular build process should work if you ask me.
dont we have a thread anywhere for this application resource stripping topic?
I did post many times about that, including creating max rsrc file on mac,
or editing exe file on win, editing maxinterface file etc etc.
I just got tired repeating that over years.