gl3 support in standalones
Hi everyone,
when creating a standalone application, it seems to default to the gl2 engine, at least it reports to be running gl2 and the gl3-shaders do complain — how can the standalone application be setup to run gl3 by default, since restarting won't do the trick after changing engine… ? I gues I've looked everywhere.
any help warmly welcomed
Max is running gl3 during export of app.
I'm on macOS but also interested in Windows solution, should it differ.
loadbang message
;
max glengine gl3
thanks. in a Max patcher this would not take effect until Max restarts — not so in a standalone?
++ this would have to be scripted before any other loadbang message occurs, for all i know about loadbang hierarchies, object added later in the patch will operate later. can this be done using the 'openactions' for a project and will those be migrated to the standalone as well? appreciated !
that will at least write selected gl engine in preferences.
on next start it will be used.
I have no idea if it works immediately in standalone.
Why don't you try ?
I hope you understand that you need to set own preferences path for standalones.
So yes, the glengine is updated without reboot, but on launch the gl3-objects are rendered bogus because the setting kicks in later, although initialised by the 'openactions.txt' in the Project. I wouldn't know how to prioritise the gl-setting before these objects are instantiated …
you need to set own preferences path for standalones.
how exactly would I go about this? I only know about the 'openactions.txt' but further preferences other than those available in the [standalone] object I am unaware of — do you know more about this? Any file to set up and/or edit? thanks.
Alas, the standalone attributes do not offer gl-specification or the like.
okay, thank you for the hint about preferences, using a custom @preffilename and editing the maxpreferences.maxpref to launch in gl3 solves it, after a reboot.
the issue is blurred a bit by the fact that I don't seem to be able to add the gl3-externals to the Project, they should be automatically added but even manually this action is ignored and they are also removed when the Project gets consolidated. Although other package-mxos are being added upon saving, this isn't true for gl3 externals and has to be done manually every time we export by copying the gl3 folder to the app's packages or elsewhere — am I mistaken?
setting preferences name is done in standalone inspector
I don't use any projects to build stuff, but add stuff manually.
You can build standalone once, add and remove all that you need / don't need
then trash the mxf file and build it again using
excludeextrernals true
line on top of build script.
That way you have mxf free of any externals, can be used on both mac and win
if there are no needed differences.
interesting hint, I don't think it is mentioned as technique anywhere — well done for figuring that out.
The build script I remember (from previous versions of Max?) and it is also mentioned in the reference but it does not show up (anymore) when attempting to build the standalone. I checked settings, file menus and all manner of options but the mentioned steps in the reference evolving around the »Collective Window« / »Collective Editor« are not available here — if you have a clue as to what is going on I would appreciate your experience. Basically, there is not Collective Editor and when building the standalone, it takes me to the filesystem directly without any script to be called.
Thanks!
When you build standalone or collective (mxf) file,
patch named colleditor pops up
that patch is located in interfaces folder
.......
Now to that gl3 stuff.
Let's take on example, I build simple test app named TEST
and insert only jit.world, gl3 message and standalone inspector.
I disabeled ALL databases, extensions , C74 resources etc
Take a good look at standalone inspector settings
then I build TEST app , but taking a look at built app :
All the stuff I disabled got anyway added, resulting in 435 MB app, what the f**** ?
-----
So, next step is to delete all that rubish, and keep only needed stuff and also manually
add stuff which was not properly included, which can happen.
In your case gl3 package.
Now this part is complicated, as one needs to know what max externals used in patch need.
If I am using no audio and no midi,
I would trash everything, from externals, frameworks, audio settings etc etc
Same for jitter - no video stuff ? -> kill it all.
Java script not used ? - away with it !
at the end I build same patch but not as app - as collective
with externals disabled
then replace original mxf with it.
---------
Max will crash if gl2 extension is not present at first run,
becaues it is selected by default.
I would hack that to use gl3 instead and forget the trouble alltogether
here, edited default engine :
That is max executable - mac version has 2 entries, because of 2 architectures.
If you are not into doing that, you can:
- option 1: edit maxpreferences after it's first run, gl2 -> make gl3
- option 2: bang that ;max glengine gl3 message ONCE !!!
if you use fixed loadbang max will bug you with that stupid dialog
even if gl3 IS current engine.
Standalone does not relaunch, because build process does
NOT copy relaunch into standalone.
So you need to copy it manually, to be able to follow that stupid routine of
setting gl engine and relaunching standalone.
P.S. posting long replies here is pain in the ass,
after some amount of lines things get scrambled, I had to re-edit my reply several times
@SOURCE AUDIO
honestly, I cannot thank you enough for this detailed response and the rigmarole you went through in explaining the ins and outs. I appreciate that A LOT.
I will get back to this for sure, at the moment I am stuck at a level way earlier in the making, since I would like to get an App simply working before looking at the optimization and further handling. I would like to send a comapct gl3-based Jitter environment to someone unfamiliar with Max or the like, ideally in form of a standalone which works upon launch without further ado (idealism, me knows) and sets off the installation plug-n-play.
Your help was top notch so far and shed a lot of light on the process. the build script is only available (i found) when exporting a patch, but not a project. Hence it never popped up earlier. Upon exporting the patch, it lists all the externals correctly but in the standalone app it now complains jit.gl.videoplane — no such object, although the .mxo is right there among all the other clutter of objects. the gl3-package got successfully included in a testrun of a small patch but not in the one I am actually wanting to compile. Besides, although the maxpreferences in the designated preference folder lists 'gl3' it still relaunches in gl2 and the gl3-objects cannot be allocated; this did/does not happen with simpler patches, where it worked after relaunch. it is very frustrating indeed and I have no means of understanding it — I'll have to cut with it for the moment.
Your latest reply remains warmly welcomed and I sure enough will profit from it soon, as many others will. Thank you.
I have this poblem with max and standalones because build process changes so often
and ane does not really know what gets included and packed into mxf file,
what gets copied into standalone structure and so on.
For that reason I prefer to strictly remove all externals from mxf file,
and add them manually into standalone structure.
No way I would ever use project form.
But please, understand that this is only my preference, being used to work
in old fashioned way as it used to be in older max versions.
that way mxf file is nothing more than a patch with a primitive checksum and few lines
of code that make the difference between a patch and collective. and collective
is needed form for standalone to auto run main patch.
-------
So if you want to try to do it this way, you need to follow this path completely.
And it will work I am sure.
You can list all externals used in main patch using
"list Externals and Subpatcher files" from the file menu.
Repeat that for any subpatches.
That gives one idea about what needs to be kept.
Another game max plays is that some objects do not really exist as externals,
but are included into executable,and some are simply not named, one example being clocker, which actually is metro.mxo
For that reason it is advisable to read all max object mapping files
in init folder.
-------
Making standalone smaller after it got compiled is one thing,
but in first place one needs to get it running.
Things can get removed later, after all runs as it should.
If you need help with compiling your patch into standalone,
post it here. I can't tell more without having a look at it.
Maybe you are overlooking something simple.
Checking that for you would take much less time than to write long explanations
and to guess what could be wrong.
If you prefer not to share the patch, it is not important, it would be enough to only place ALL
externals that your patch and subpatches use into one patch, no need to connect anything and to post it here...
I can confirm that Standalone with modified max executable starts with gl3 engine
and needs no further actions to use it, or messing with preferences.
I compiled few gl3 example patches to test.
Even freeware hexfeind can do that in few seconds, even windows version.
https://hexfiend.com/
It does not matter for mac, but on windows when it gets compiled,
exe file gets preferences name added inside,
opposite to mac version which does so by writting it into rsrc file.
For that reason it is better to edit executable after building the stabndalone.
I didn't follow along on this entire thread, but for the original question of setting gl3 in standalones, simply add an init folder to your standalone (if not already present) with a text file that contains:
max glengine gl3;
see this thread for more on using gl3 in a standalone - https://cycling74.com/forums/jit-gl-mesh-%22point_mode%22-is-not-a-valid-attribute-argument-in-built-app
Thanks rob,
this method saves any new user from having to restart a bogus app before gl3 kicks in. Very helpful hint.
I am now script-copying all necessary files automatically into the standalone from Max itself, also te gl3 package. While the app is huge, it works on my machine at least — though not on other macs, which is kinda what its about really...? I am aware there are tons of threads on this already and there seems to be no (or no easy) solution to make the apps work without asking the user to perform workarounds or undergo security risks. But I am sure enough stuck at the next level now: App is fine, though not on another mchine (App »can't be opened.« period)
thanks again Source Audio,
theoretically following your instruction above, you mention the removal of unnecessary, unwanted stuff, I guess this is trial and error… not sure I'd know what is needed other than the externals listed in the patch. Talking of which, do you simply delete everything and copy the externals listed into the externals folder? it does get tricky in this case when using gen since its operators are listed as regular .mxo but nowhere to be found, neither even in the directory they are listed in, nor mentioned in objectmappings anywhere. How do you handle this? is gen/jit.pix/jit.gl.pix all we need in this case? or is it enough to flag gensupport in the standalone object? Well, I guess you had asked for a patch instead of complicated descriptions so I should respect that ;) — thought I'd throw the question in here before trying all manner of things without orientation
you are really right, I need a patch to tell what you can remove.
if you use gen , then activate it's support in standalone inspector.
Problem with security on a different mac ...
I think one still can rightclick and open or not ?
another way to reduce satandalone size is to remove architecture in case it is not needed.
If you know it will only be used on M1 mac, you can strip x86_64 code.
Size will drop to almost half.
in case of the app I am wanting to share, the dialog simply states »cannot be opened« without further options and without even reaching the security border, i.e. in system preferences the app does not show up as blocked so there is no way to make it work or tweak its handling. I can't test right now but perhaps removing the @bundleidentifier entry could help?
Alas, stripping the redundant architecture I am aware of and will sort once everything else is in place.
Thanks once more.
bundle indentifier will make no difference,
you can try to control or right-click on app
and select open.
Or maybe remove apple quarantine xattr
by typing sudo xattr -cr in terminal and drop the app.
You can also doubleclick standalone executable in MacOS folder, to run it
via terminal and see if it outputs any errors and warnings.
I'm pretty sure the right-click to open workaround only works on 10.15 and below, could be wrong.
I believe you can make shareable simply by ad-hoc code signing the app (using dash "-" as dev-id). See this recent-ish thread, and the article it links to for code signing process (no need for notarizing) - https://cycling74.com/forums/issue-with-code-signing-mac-standalones-with-hardened-runtime
Please let us know if this works.