Building an application from projects ?
Hi there,
I never built applications from project, only from top-level patchers.
1/ it seems that the build windows (with scripting options) doesn't appear when you click on "Build Collective/Application". can be a bug ?
2/ I need 3 patchers to be running in my application (basically one for visuals, one for sound and one for controlling both). If I create an application, and launch it, it only runs one patcher.
Any experiences ??
That's pretty urgent and I cannot figure it out in the documentation too (I may miss something for sure)
I can confirm.
I have 3 Top-Level Patchers that have to be opened at the startup of my application.
If I build using the Projects > Build Collective/Application feature, it builds BUT only one top level patchers is opened.
I found a workaround.
I still keep working with Projects which is VERY useful.
I consolidate, I include files in my projects.. ok.
Then, when I need to build, I quit Max.
I open one of my top-level patchers, I edit build scripts:
- I add all Toplevel Patchers I need to open on startup by Clicking on « Toplevel Patchers… »
- I include ALL folders from my project folders one by one (code, patchers, data, externals, others) by clicking each time on « Include Folder ».
Then I build. Of course, I save this script by clicking on « Save Script… » in order to build easier next times.
It works fine and keep me using Projects which is a VERY useful feature in Max.
Nothing really smart here, but a nice workaround I wanted to share.
Yes I confirm that the workaround adds some mess too (side effect..)
And I can confirm that Projects doesn't seem to work well when you have multiple patchers top-level.
I have 3.
I build.
Only one opens.
I delete the application, I rebuild it after having altered the “open on project load" of some patchers. I close Max. I reopen it, I build, another one is the only one top level patchers to be opened & so on. I don't understand why. I even also checked the text file .maxproj and toplevel: 1 seems to reflect correctly my modification (which is more scary because which part underlying decide to include this or that as a top level patcher so ??)
This inconsistent bug couldn't happen that bad for me at that time . I trusted Projects but now I have to find a workaround
So.
After long hours of workaround seeking, I found the most obvious one, as usual.
Building an application with 3 top-level patchers was impossible. Ok.
So I just... created a patch including these 3 top level patchers as .. abstractions.
So I now have only 1 top level patcher, that can be built as an application et voilà.
2:10 in the morning or night or whatever as I'm so jet lag and the solution appeared.
of course that's obvious, now.
I hope if someone got this one day, it will find here the most absurd solution I ever found:
-> branching 3 orpheans branches to one at the top
if i am not mistaken that is the expected behaviour.
there is a bunch of solutions how one can open additional patcher windows, my preferred one is to add another layer on top, one small main patcher with the other three "top level" patchers inside... when everything works, minimize that real top level patcher to size 0 0.
one of the reasons (or let´s say benefits?) for this is, that only when launched from another patcher you can control the order in which patchers are loaded - and the order might be relevant.
This is what I did in the end.
And the weird unconsistent behavior when building an application with more than one top-level patchers in a Projects bugged me. Sometimes it built something opening 1, or 2 or even sometimes my 3 top level patchers so I took this as a possible normal behavior.
Everything is okay now, but I'm still not sure about the benefit of having put all my 3 processes into 3 differents patchers. I could have done 3 different applications communicating by udp maybe. But I won't change it anymore. It was intended to work on a mac pro and it is so optimized on gpu and more that it works completely smoothly on my late 2016 mac book pro :-D