Standalone file size in Max 7
I haven't yet update to Max 7.0.1, so maybe this is different, but in Max 7 standalone apps are GIGANTIC. My simple, MIDI and java only patch suddenly became a 330MB application. Upon further inspection, the standalone contained every .mxo in the search path, including everything for jitter, everything for MSP, etc. The Chromium Embedded Framework is a whopping 142MB, and I'm not sure what it does (though removing it will make the Finder throw a 'this application is damaged' error). It included all the 'extensions' in the extensions folder, even though I thought I'd told it not to via the [standalone] object. It seems to include all the picts, all the SVG interfaces, basically it includes EVERYTHING, and I've no idea why. IIRC, on Max 6 it would parse through a patcher and only include externals that were in use in the patcher.
This is on OSX 10.9.5. So, what's the reasoning behind generating these massive standalone apps?
This I also would like to know!
+1
+1!
It used to be just to be as large as mentioned on other threads. So this time I tried removing jitter as before, but then the graphics didnt draw in the executable. So this may be a manifestation of one of the long-standing problems with object oriented programming, that eventually everything is part of everything else and there is no way to make it small without alot of work. So this could take some time to fix, especially as it was already a problem.
hi guys. we're aware of this issue and are looking into possible solutions.
I was able to reduce standalone size quite a bit, by removing
unnecessary crap, but my main "to kill" would be the Chrome Embedded Framework,
which I have not yet managed to remove, as Max refuses to start without it,
even though one might expect that it is needed only for maxurl object.
+ 1
Will have to hold off updating releases before this gets fixed.
Yup, I'm on Mac a 10.8.5 system, and with Max 7.0.1 I'm still getting 300+ MB standalones, when building from tiny patches.
I did submit an official report to Cycling '74 staff, and they said they're working on it. I trust they will sort it out in time, but as others have said here, it's going to cause me to hold off on fully making the switch to Max 7.
+1. This is a very important issue for me.
+1,
a 12 Mo .mxf generates a 350 Mo .app, only when by chance the builder doesn't inexpectively crash. Presently unable to work with standalones.
+1,
Is there any indication if this is this a priority for the next Max update? The Max 7 icon is sitting in my taskbar... taunting me.
I'd also love to get a status update on this. Is this on the list for the next update?
In the release notes for the March 12 release of Max 7.0.2, it says under "Fixed Bugs":
CEF: can remove CEF for smaller standalone apps
(CEF is of course the aforementioned Chromium Embedded Framework.)
I just created a small test patch, and turned it into a standalone. I didn't see anywhere in the standalone object where I could ask Max to omit the CEF from the build.
In the Finder I looked inside the standalone build, and manually trashed the Chromium Embedded Framework.framework directory from Contents/Frameworks. The app was still able to launch fine.
That is, I suppose, the "good news". However:
• Even with CEF removed, this standalone is still 212 MB.
• It took 29 seconds for Max 7 to complete the build.
• My test patch is included below, and a screenshot of it attached for quick reference. The standalone size and build times are, obviously, disproportionately huge for this patch.
The features of Max 7 are looking AMAZING. This performance with standalones, however, needs work.
Leigh, thanks for doing the test. It's such a shame that standalones now take up such a huge amount of space.
I often create small tools for my coworkers for testing audio, MIDI, OSC, etc., which obviously I can keep using Max 6 for to keep the file size down. What's more of a problem is creating synthesisers and feature-rich tools to release online. Hosting on my end, and downloading on the user end is problematic with 20+ downloads being 200-300MB+ when they used to be 10-20MB.
I raised this problem on the Max/MSP Facebook group where Jeremy from Cycling 74 responded:
"(in regards to removing excess files, including CEF, in the Max 7 standalones) Most of the stuff there really takes up negligible space, though, CEF and gen being the biggest culprits. In the future, all bets are off, of course -- we reserve the right to start using CEF or clang in other parts of the app, but at the moment (7.0.2), that stuff is safe to remove."
To me this is an indicator that Cycling have given the inclusion of CEF a greater priority than standalone file size. So I'm doubtful this will get better.
C
I wonder if C74 will drop standalones after a few more major versions.
I haven't actually checked this yet (been very busy this week), but in 7.0 and 7.0.1, the standalones were also including EVERYTHING from the cycling74 folder - so you'd get all the Jitter objects built into your file even if you're not using Jitter at all. It'd include max/msp objects you weren't using, even things like the example/tutorial image files and music data files and such. CEF was the 'biggest' culprit, but all those little files add up (to somewhere in the ballpark of 50MB!) if you're really just doing MIDI stuff.
Used to be, Max 6 was smart enough to only include things you'd actually used in the patch (or even not include anything at all, and you'd have to actively tell it which things to include). I'd much prefer it assuming I want to include 'nothing' rather than everything. I plan to use Max for an end-user firmware updater frontend for a piece of hardware I'm developing, it's really just some buttons and some MIDI signals, and a 100-300MB app download just to get a 332kb firmware into a user's hands is a bit insane.
Mushoo - I believe that "including everything" has been fixed, although there is now a clang.mxo (in /Contents/Resources/C74/extensions/max/) that I don't remember seeing before, which is about 40MB just itself.
Chris - thanks for sharing your experience and this further info. I, too, like to build little utility apps in Max. Obviously disk space has gotten a lot cheaper over the years, but still, 340MB for what should be tiny utility seems egregious to me. Of course, there's going to be more overhead when building in an environment like Max, but in Max 6, this same test patch builds at about 46MB. A sevenfold increase in standalone size isn't a change I welcome in Max's evolution.
Obviously disk space has gotten a lot cheaper over the years
Well, yes and no. With solid state drives becoming more and more standard, the size of an Apple computer hard drive has actually gone down, though it will of course go back up in time.
But the main point is that users expect file size to be proportional to the complexity of the app. For a simply little unifunctional app, I think that a 300+ MB file size would definitely raise eyebrows. I'm still hoping to get my apps on the app store, but I hope there is a future for standalones.
the size of an Apple computer hard drive has actually gone down
I was looking at the 13" retina macbook pro the other day - 128gb internal SSD with no option to increase it, on the low end model. The only 13" retina model that has a vaguely configurable SSD is the high-end one, where you can choose between 512gb and 1tb. For horrendous amounts of money...
I think the issue is that this increase in file size is effectively removing a portion of Max's uses - putting people developing distributable applications with Max behind expanding their market by making the software more accessible.
@Leigh - clang.mxo was already there in Max 6.0
I work on a project since Max4 for a Mac:
in Max 4 the standalone was 24MB, in Max6.0 it was 52MB, in Max6.1 it's 100MB (with all unnecessary files removed from the packages).
Just tried in Max7-> 363MB without removing unnecessary files (I need time to check what is necessary in all this mess).
If Cycling's licensing policy for demo usage remains only stated as "no edit", I consider proposing to download my product versions not as standalone but as crossplatform .mxf files. So the Max 7 demo version could be in the role of the former Max runtime. Do you think this as a viable solution?
No. I already have to convince people to download and install Java a bunch of the time (shellaccess script). Having to make everyone download Max, and then Java, and then my patch (in a way that would let them then view the 'source code' of it, even if they can't 'edit' it), is unacceptable. The whole point of the standalone system is that an end-user doesn't need to do any extra work other than download your standalone.
hi all,
its really disturbing, that standalones are that big.
on my computer it takes 20-30 seconds to save a single standalone app.
most of my jitter systems need 3-4 standalone apps communicating via osc.
so it needs 2 minutes only for saving, then i have 1GB files on my hard disk.
if i do jobs with max, i often have to do some quick fixes at the last moment on stage.
impossible with max7.
for me there is no way to use max7 at its current state.
why isn't it possible only include the externals and extensions when used ?
it worked well in the past.
why is the "Chromium Embedded Framework.framework" added to every standalone ?
there should be a much more clever way to deal with that.
best,
petcode
Here's a little more insight into it from the full conversation I had with Jeremy on Facebook.
Jeremy
In 7.0.2, if you aren't using jweb, you can safely remove the cef framework from your app. No need for a 'main library' copy (there is no situation I can think of where you would ever need such a thing, btw). However, if you're planning to distribute via the Apple Store, this will cause other problems.
Chris
Would anyone else find it useful to have a bunch of check boxes to enable/disable the inclusion of certain libraries within a standalone. This could remember the way you configured it from last time, or even have a bunch of presets you can keep. Ie:
[x] CEF
[x] MSP
[x] MIDI
[ ] JITTER
[x] JAVA
... etc
Going through the folders after each standalone build to delete certain files to lighten up the load ends up consuming a lot of extra time and concentration.
Jeremy
We have this on our radar, but as it's a bit of an advanced user feature, and as most users who are seriously building standalones have the skills to write a shell or bat script to take care of this, it's not the highest-priority item. The current functionality is intended to essentially just work, so that any user can take advantage of the standalone feature with little additional knowledge or setup required.
Chris
I can totally appreciate that and take it on board. I'll make a tool that I'll share to do this. Is there a public list of each of the standalone's resource files and what functions depend on them? Or is it more of a game of trial and error? There's quite a few files there.
Jeremy
No list, but much of the stuff there is fairly self-explanatory (e.g. max, msp, jitter, m4l folders). clang is used for gen. ad contains audiodrivers, mididrivers is for midi drivers. Most of the stuff there really takes up negligible space, though, CEF and gen being the biggest culprits. In the future, all bets are off, of course -- we reserve the right to start using CEF or clang in other parts of the app, but at the moment (7.0.2), that stuff is safe to remove
.
enable/disable certain libraries with the [standalone] object is really a great idea !
then we would be able to do this once for every application.
sounds not so difficult to implement.
and btw. i dont think, that it is a pro user feature.
wasting time looking at the beachball is no fun for all users ;-)
pc
Chris, thanks for the additional info. That helps to know that clang.mxo (meaning, of course, "c lang") is for the gen object only.
Still, I do not understand Cycling's thinking behind standalones. On one hand, the standalone object in Max 7 now includes a field to enter the application's bundleidentifier (ex: com.refusesoftware.com.UglyVSTiInterface ). I saw that while demoing Max 7, and got excited, thinking, "oh they're getting more pro about having production-ready standalones". (Up until now I've had to go in and edit the Info.plist file, after the standalone has been built, to change those bundle strings.)
On the other hand, it's a debacle from a production standpoint to not be able to build an app, even with clang.mxo and CEF manually removed, that's under 170 MB. (And I only find this out after buying the upgrade, since I couldn't try building any further standalones after my Max 7 trial had expired.) I offer a bunch of free utility applications through reFuse Software, the largest of which is 30MB in size. Adopting Max 7 into our production flow would create an unacceptable amount of bloat. So, it's back to Max 6 for now.
Yes, unfortunately I'm in a similar position to you, Leigh. I used Max 7 for about 2 weeks before realising how bloated the standalones were. Since then I haven't touched Max 7 again. Which is such a shame, since I was really loving the updated UI objects and some of the other great feature adds.
Agreed, sounds like we are in the same boat there!
FWIW I doubt I will crossgrade from m4l until there is more emphasis on lower level control. I love the idea of gen, but 300$ is a lot if all I'd use it for is a more efficient synth in ableton. Patricks comment about growing file sizes reaffirms my confidence in learning other software frameworks.
First off, I totally sympathize with your desire for smaller standalones. Let me just put that out there.
However, please understand that there are a number of conflicting requirements for the standalones feature. Primary among those is providing some form of reliable support for the App Store. Due to Apple's requirements, there are some non-trivial technical challenges involved in eliminating Frameworks from our application bundle (e.g. CEF, the largest single new dependency in Max 7). We're working on it, though.
As for the inclusion of externals, extensions and media, consider these points. Any patcher which uses scripting, JS or mxj can potentially instantiate arbitrary objects which we cannot determine while building a standalone. Many Jitter patchers expect the full array of shaders, materials, and so on to be available. Likewise for Java classes or jsextensions, fonts and so on.
This combinatoric nightmare, combined with the fact that many users were turning to support with complaints about non-functioning standalones (due to the above factors), caused us to reconsider how we approach them. Rather than forcing users to opt-in to certain features, we're asking you, the advanced users with specific requirements, to opt-out. At the moment, you need to do this yourself by removing elements from the frameworks and resources folders (we've had higher priority issues to deal with since 7.0.0 was released), but that won't be the case forever. Scripting this removal is fairly straightforward using any number of tools (one could put together a menu-driven Ruby script to handle this in less than 30 minutes).
Anyway, right now our first priority along these lines is to solve our remaining App Store issues. As you may be aware, submitting apps for rejection by the App Store can often take over a week. So this is a somewhat drawn-out process, but we have no reasonable option. Once the parameters for a functioning, App Store-compatible app are known, we can (and will) spend some time on opt-out tools via the 'standalone' object.
Until then, thanks for your patience and support.
hi Jeremy,
Thank you for the reasoned and informative response.
Any patcher which uses scripting, JS or mxj can potentially instantiate arbitrary objects which we cannot determine while building a standalone...[+]Jitter patchers...[+]Java classes
I figured there was some concern over open-ended scripting and wanting standalones to cover all bases, although I didn't realize that there were that many points of "open-endedness". Still, for my primarily-audio apps (none of which go onto the App Store) I usually would use none of those elements (no Javascript, no Java, no Jitter).
Rather than forcing users to opt-in to certain features, we’re asking you, the advanced users with specific requirements, to opt-out.
Again, this seems like a sensible approach. Cover all bases by default, and let advanced users pare it down from there. And I would be comfortable making my own script/tool to automate the removal of extraneous frameworks and resources.
What would help enormously, however, is some documentation of which frameworks and resources are needed for which objects. For instance, I only know now that clang.mxo is used for gen because of the conversation between you and Chris that Chris posted above.
In short: A little map of the structure of standalones would go a long way in taking the guesswork out of this process.
cheers,
Leigh
As a noob, my question is then: How does one identify all the erroneous files to remove? My app jumped from 98mb to 348mb. Removing anything ( audio, jit, folders) appears to brake it, which is odd as i'm only using midi and math.
The app in question is for personal use , so im not really wanting to become a full time scripter to code things out - not that i have the time to learn new skills these days.
Other than that Max 7 is feeling powerful and smooth.
most of my plug-ins, patches and bpatchers are 30 kilobytes long. and my apps are usually around 5 mb, of which 80% are custom image files.
350 mb is not only too much if you make some custom desktop utilities for your personal use, it would be even to much if you publish a commercial DAW program. (yes i know, some programs are that big - which is why i dont buy them anymore.)
This is the reason why I'm still using Max 6 all the time (just opening Max 7 from time to time to check differences, but I do not feel the need to switch yet).
Completely agree with Roman and the other posters on size matter & with Leigh on the necessity of better documentation, even for "advanced" use.
Your plug-ins, patchers and bpatchers don't reflect the binary (runtime app) and library dependencies (objects, frameworks, etc.) which are required for a functioning standalone application. If Max as a programming environment is too big for your taste, I am truly sorry. I don't think this line of inquiry is particularly constructive, though.
As for Leigh's and Saucehp's concerns, if I have some free cycles, I will put together this list, or write the menu-driven Ruby script I mentioned above. As I said, we have plans to improve your opt-out control in future releases, but we need to first come up with a reasonable approach to our CEF dependency. Again, thanks for your patience and support in this matter!
I've just stumbled into this issue too. My Max 7 standalone was around 300 Mb. Deleting all files that weren't necessary (midi patch here only!!) I've managed to get it around 140 Mb. And I use very little objects, because almost all of the logic was done using a mxj (java)object. I could go back to Max 6 but then I loose the Project manager which I love. I'm this disappointed that I'm considering alternatives like JUCE, but that will involve a huge learning curve (from Java to C++ for starters). Sorry for the rant, but this was a real eye opener.
Hey Brons,
Interesting you should mention Juce - and MIDI. That's basically what I'm leaning towards too (don't have a ton of time to devote to it at the moment, but it's on my to-do list). My need is for MIDI and shell/bash access though, and I'm trying to getting away from Max because I need Java for shell access, and it's not a default install on OSX anymore. I don't like forcing people to install it. I'm OK at Java and relatively good at C++ -- just not at C++ for a full on OSX application (Arduino...). So... want to shoot me a PM? I figure we can at least trade emails and see if we can't work through the JUCE process together a bit - two heads are usually better than one, and it seems like we need pretty similar things. Let me know.
Mushoo, I was looking for a way to PM you, but this forum doesn't allow you to do this?! So here is my reply to you (and everybody else interested).
Yes, Max7 isn't playing nice to me at the moment, so I'm just back at Max 6 now. I must say I'm getting used already to Max6 again and it feels somewhat refreshing after using 7 for almost a year (?) now. No more nagging pop-up bars in every window and the Inspector window is now working as it should. I've should have done this way earlier, but I was to stubborn in the believe that a later version is always better then a previous one. Cycling 74 has taken a direction I'm not comfortable with.
In the meantime I'm surfing the web for all kinds of info to what Juce actually is. It has a very comprehensive API, but I feel there are a few snags. As I'm on Windows 7 it looks I'm dependent on Visual Studio for the compilations. The Introjucer has a build-in code editor, but is this really equal (like in my case) to Eclipse? And what about the GUI creation? Can we build dynamically complex GUI's as in Max? Questions...
Other things to concern for me are timers. In Max we have all kinds of timers, metro's etc. for firing events. Since I'm in the process of making a advanced midi looper (search for Zyklus Improvisor, an 8 track midi looper with real-time recording and harmonisation possibilities), I have a feeling to make something similar in Juce will take a life time of work. I did code the logic in Java, but still relied on midi and timer objects in Max. That has to be recreated in Juce somehow. I'm not sure what to expect if I go the Juce route, but I probably get my hands very dirty even to get a single midi note into the program.
Just some considerations on this side.
I couldn't agree more. Today, I also switched back to Max 6. The gui is so beautiful, it's like I'm using Max 8!
Getting rid of borderlines was the biggest mistake Cycling '74 ever made. I just can't believe how crystal-clear
my patch is looking again. Max 7 has so many slider-designs and all of them are awful. For me they are completely useless.
Try designing a two way slide switch (function of toggle, but using slider), good luck...I know this is a bit offtopic,
sorry I can't help you with the other stuff.
Hey folks, just wanted to mention that we're very aware of the standalone size issues (which are related to our Apple Store acceptance issues) and have improvements coming soon to address these. Don't give up hope quite yet.
I have also complained about Standalone File Size a while ago.
Things have changed a lot since CEF Framework is not a MUST anymore.
My last simple audio Player App (Max 705) is now just 26 mb.
That is way better than with initial max7 version.
Any improvements in Max706?
Yes, the 'standalone' object now features options for disabling CEF, gen and redundant copying of Max resources. With all three disabled, your standalones will be smaller than those produced by Max 6. And disabling CEF will get you past the App Store review process.
Ok, just installed 7.0.6 coming from 7.0.1. When "CEF Support", "Gen Support" and "Include C74 Resources" are disabled the file size went from 235 Mb to approx. 36 Mb. Now that's more like it! On a side note: when building it for the first time I got all kinds of messages that the object definitions were made with an older version (7.0.1). It used the externals that were stored in my project folder instead of the freshly made ones in the Cycling 74 folder. Removing this folder did the trick.
How did you get C74 externals into your project folder? Did you explicitly add them to your project and consolidate?
If so, we should probably try to prevent that from happening. Thanks!
Good question and I wondered that myself too. I know for sure I didn't copy them manually from the Cycling 74 folder to my project folder. And normally I don't use consolidate, but I can't rule it out either. One of the problems when making a stand-alone in combination with Java classes and jar's is that Max can complain that it can't find a certain file. It's not that easy to make a stand alone without error messages. So one does a copy here and a copy there to make the messages go away.
Thanks to the new 7.0.6: Now I can propose downloadable releases of my software. But before that , can anybody explain why the app made with OSX Yosemite weights 82.6 Mo and the folder made with Windows 7 64x weights only 38 Mo. Exactly the same sources (and standalone object options)?
Universal 32- and 64-bit binaries on OSX.
Just downloaded Max 7.2 on OSX to see how standalone sizes are doing.
First thing I encountered was a bug with the [standalone] object's inspector interface! It has a checkbox for "CEF Support", which seems to be operating in "reverse polarity" of how it should.
I did two builds of an otherwise identical project, one with "CEF Support" checked, and the other with it unchecked.
Standalone size with CEF Support unchecked: 346MB
Standalone size with CEF Support checked: 198MB
Can anyone else confirm this bug?
PS: For the record, I had the "Gen Support" and "Include C74 Resources" boxes still checked in these test builds.
I went ahead and did some further test builds, this time with the [standalone] object's "Gen Support" and "Include C74 Resources" boxes unchecked. I repeated as above, one build with CEF Support unchecked, and one with it checked. The results are even more confounding this time around.
In both test builds, the CEF Framework folder was included! (This is inside the application bundle, Contents/Frameworks/Chromium Embedded Framework.framework)
The contents of the Contents/Resources/C74 folder also changed, depending on whether CEF support was checked or not. See the screenshot included. As you can read in the Path Bar at the bottom of the two windows, the top one was with CEF support checked ("wCEF"), and the bottom one was with CEF support unchecked ("noCEF").
So, not only is the "CEF Support" preference not being correctly read, but it is also causing "a full set of externals, shaders, Javascript support files, etc." to be copied into the standalone, as if the copysupport attribute (aka "Include C74 Resources" in the inspector) had been turned on!
Confused? Me too! What is going on here?
I confirm the bug: size in 7.1 = 82Mb, in 7.2: 353Mb
Help!
I can confirm that there's a problem the first time you build a standalone. Subsequent builds appear to be working correctly. I'll do some more research, sorry for the trouble.
Update on the aforementioned project build, with Max 7.2.2:
In [standalone] object, all of the following are unchecked:
"CEF Support"
"Gen Support"
"Include C74 Resources"
The standalone application is now building at a more reasonable 74.5 MB in size. I haven't done extensive testing, to toggle those [standalone] object options on and off, and check that they all behave properly.
This same application builds at a trim 35 MB with Max 6. I understand that extra overhead is the price of progress sometimes, just noting this for the record.
My guess in this case is the inclusion of both 32- and 64- bit binaries in a single Mac application bundle makes for roughly twice the size?
great informative thread, here, and great size reductions with the standalone object inspector, thanks!
I see two more possible improvements re. size:
- included packages have both mac and windows externals copied to the standalone.
- are the max extensions (esp. maxxslt.mxo 5.3 MB, sqlite.mxo 1.7 MB, yaml.mxo 0.8 MB) necessary?
i really appreciate the effort which has been put into making things possible again but i still feel the need to reply to this:
"Your plug-ins, patchers and bpatchers don’t reflect the binary (runtime app) and library dependencies (objects, frameworks, etc.) which are required for a functioning standalone application."
they didnt in max 4 -6 either. yet i can still remove anything unwanted there. programmatically or, as a workaround, even manually.
in max 4 you put everything you want to include in a folder, select this folder as "include" and it is included. and the internals i think. the rest is not. it worked for 15 years, why change this?
i think you missed the point when you do not even consider for a moment that it could have been questionable decision to make a single object depend on a 100 mb library. a single object is not more important than basic features of the enviroment.
the requirements of the apple store (as one of thouands of possible reseller partners out there) wasnt a very good argument either. :)
max 7.3 still does not automatically clean up my kitchen after making coffee.
LOL. We're saving that feature for the magical release number "7.4".
As for your other concerns, I hear what you're saying. However, I would contend that our use of CEF (File, Reference, Package Browsers, Authentication interface) has enriched the software significantly and permitted us to implement features which would have been impractical otherwise. Likewise, the heavy clang dependency for Gen, well, do you want just-in-time compiled DSP code or don't you? Every technology has its cost, and these are ours, laid bare. At least we provide a means to turn those features off when exporting standalones now.
@Diemo, some of the extensions may be necessary, some not (maxxslt is almost certainly not, sqlite might be if you are using database functions in JS, yaml... not sure). It was determined that a savings of ~5MB did not justify the extra, potentially error-prone effort of weeding that stuff out.
Yep, sqlite.mxo seems necessary as there are ~12 cyan-coloured errors in the standalone console otherwise (although the patch seems to function).
Removing the 5MB of maxxslt.mxo has no negative effect, and can make a difference (like, just passing under 200MB =-)
Didn't bother to test removing yaml.mxo.
+1. Would be so nice to send teeny standalones as teeny zipped email attachments.
Hello, revamping old thread here. What can we eliminate from standalones as of Max 8.3 ? I so far have eliminated CEF, MaxPLuginScanner.exe, and maxclangmxe64, cos they where the biggest stuff I found in the resources folder. Is there anything else to get rid of? My app folder is 129 Mb now, would be awesome to reduce this. Thanks!!
I still get rid of the ones you mention when I don't need them, and beyond that simply do some trial and error for any remaining ones I get rid of - I'm far less finicky about this than I was originally. Chalk it up to old age! :-)
Yeah thats whta I did!! But in Mac it has been a nightmare. A user is helping me epically in this other post with this issue. I couldn't care less about Mac but sadly half the people use it.
https://cycling74.com/forums/jit-window-issue-win-to-mac-patch-port/