99benns

I use Max in a live setting running VST plugins on a Mac. The problem is that sometimes plugins will crash, which then crashes Max. I'm trying to get around this by running groups of plugins under completely separate Max applications which has helped (plugin crashes, only part of the system crashes, it auto restarts in 5-10 seconds). However Max sometimes doesn't like being run more than once:

-Sometimes it will crash if I try to open the audio window

-If I change a setting in the audio window, it seems to change for all applications

-If I open 2 different max apps at the same time, one of them will crash, therefore I must wait a few seconds before launching each app

Does anybody have any experience of running more than 1 Max collective/application on the same computer at the same time? Perhaps this isn't the best solution? Any advice would be really appreciated!

I use Max in a live setting running VST plugins on a Mac. The problem is that sometimes plugins will crash, which then crashes Max. I'm trying to get around this by running groups of plugins under completely separate Max applications which has helped (plugin crashes, only part of the system crashes, it auto restarts in 5-10 seconds). However Max sometimes doesn't like being run more than once:
-Sometimes it will crash if I try to open the audio window
-If I change a setting in the audio window, it seems to change for all applications
-If I open 2 different max apps at the same time, one of them will crash, therefore I must wait a few seconds before launching each app

Does anybody have any experience of running more than 1 Max collective/application on the same computer at the same time? Perhaps this isn't the best solution? Any advice would be really appreciated!


running-multiple-max-applications-on-the-same-machine

It should be doable, but there may be issues with how things are shared. Example: if you run two collectives or two .maxpats, any [send] and [receive] will crosstalk. If you run them as standalones, they won't, which is usually what you want.

I believe the audio window changing for all applications is expected behavior if you just have one audio device (any changes will necessarily change for all applications). However, I don't know if you can choose multiple different audio cards for different applications...?

Would probably be tough to track down the reasons for the crashes. Maybe try some dirt-simple patches and build up until crashes. Try some with no audio at all, then with simple audio, etc. and see what happens. Also, if it's the actual audio window opening that's causing the trouble, you can use [adstatus] to make changes from within the patch (go to Edit mode in the audio status window and all the commands will be there for you to explore, or check the help file). But, it might be changing the actual values which causes the crashes...in that case, [adstatus] wouldn't help.

Quite possibly it's due to interference of the VSTs as well. Not sure what to say for that one...are some more stable than others?

this -n option allows you to open several instances of a same application.

Otherwise I don't seem to have problems running several Max, max applications, although i don't do it extensively.

did you try the following command line :open [YourMaxAppPath] -n
?
this -n option allows you to open several instances of a same application.
Otherwise I don't seem to have problems running several Max, max applications, although i don't do it extensively.


Adrian Freed (CNMAT) mentioned that he will run more than one instance of Max on the same machine to take advantage multicore processing. For example, it allows one instance of Max to handle the audio while another does the video.. with OSC handling communication between the two (if I understood him correctly). Not sure of the details but apparently (once you get it set up properly) it works quite well in terms of speed and performance.

Adrian Freed (CNMAT) mentioned that he will run more than one instance of Max on the same machine to take advantage multicore processing.  For example, it allows one instance of Max to handle the audio while another does the video.. with OSC handling communication between the two (if I understood him correctly).   Not sure of the details but apparently (once you get it set up properly) it works quite well in terms of speed and performance.


This did it for me.. (given the default installation of the latest version of Max on OS X) Type the following command line into Terminal:

Not sure what else would need to be done but it seems to work. I have one patch running with overdrive on and another patch running with overdrive off...

This did it for me.. (given the default installation of the latest version of Max on OS X)  Type the following command line into Terminal:

Not sure what else would need to be done but it seems to work.  I have one patch running with overdrive on and another patch running with overdrive off...


Wow.. this works really well. The option of having separate global settings is huge... like multiple worlds. OSC communication can be setup in just a minute. Combined with route and gated send/receive you can easily choose how much data flows between the two apps.

Wow.. this works really well.  The option of having separate global settings is huge...  like multiple worlds.  OSC communication can be setup in just a minute.  Combined with route and gated send/receive you can easily choose how much data flows between the two apps.


I, like Adrian, have run multiple instances of Max standalones quite a bit, as a way scaling up what can be done on one machine with Max. One important trick to be aware of is to name each preferences folder uniquely for each standalone (include [standalone object in your patch, and look in getinfo). If all applications are reading/writing from/to the same preferences files, that definitely can cause issues (including crashes).

OK.. I misread the original poster. I was talking about Max itself.. not just standalones.

Without hijacking the thread.. if I am using terminal to start another instance of Max, do I need to create a unique prefs file within terminal? If not, how can I specify that the second instance of Max uses a given prefs file?

OK.. I misread the original poster.  I was talking about Max itself.. not just standalones. 

Without hijacking the thread.. if I am using terminal to start another instance of Max, do I need to create a unique prefs file within terminal?  If not, how can I specify that the second instance of Max uses a given prefs file?


hmmm.... that, i don't know... each max instance will look at the default preferences file, that's nearly sure, but if you want to create a new one and set a second instance to use that new one, i have no idea how to do it....

Hey thanks for all your help. I've actually compiled 4 separate stand alone applications:

-1 for imposcar2 (this crashes most frequently!)

-1 for my MIDI routing (has never crashed)

I use the IAC bus to transfer the info between apps.

There's no cross-talk between sends/receives

I've used adstatus to select certain audio options, this has worked well

The main problem is that if I try to open more than 1 app at the same time, the rest will crash. I've even compiled 2 empty patches to stand alone apps, if I launch both within a couple of seconds of each other, one will crash! hmmmm

Hey thanks for all your help. I've actually compiled 4 separate stand alone applications:
-1 for NI Kontakt and Massive
-1 for 3 instances of Omnisphere
-1 for imposcar2 (this crashes most frequently!)
-1 for my MIDI routing (has never crashed)
I use the IAC bus to transfer the info between apps.

There's no cross-talk between sends/receives
I've used adstatus to select certain audio options, this has worked well

The main problem is that if I try to open more than 1 app at the same time, the rest will crash. I've even compiled 2 empty patches to stand alone apps, if I launch both within a couple of seconds of each other, one will crash! hmmmm


...but, i don't know. many possible origins of your problem. MIDI routes conflict ? plugins instability ? conflicting audio drivers setup ?

that's some heavy setup ! ;)
...but, i don't know. many possible origins of your problem. MIDI routes conflict ? plugins instability ? conflicting audio drivers setup ?


@vichug You can use the project feature to have specific search path.

@Emmanuel, ah but that works only if you have a compiled application out of a project, right ?

I am drooling at the possibility of running Max multiple times --- I'd love to be able to separate my MIDI management from my audio stuff, the latter of which is still not reliable in Max 6.

Also, DDMF has an intriguing product called Metaplugin that will allow 32-bit VSTs to be loaded into a 64-bit space so that opens the doors a bit too.

I am drooling at the possibility of running Max multiple times --- I'd love to be able to separate my MIDI management from my audio stuff, the latter of which is still not reliable in Max 6.
Also, DDMF has an intriguing product called Metaplugin that will allow 32-bit VSTs to be loaded into a 64-bit space so that opens the doors a bit too.


 it is possible. I was just talking with some folks who know such things.. and they specifically do it to handle audio and video processing separately. I will get in touch with them again and find out more details. I suspect they may have either a) installed Max more than once on the same system but in different Applications folders and/or possibly under two two admin accounts with full access privileges (thereby creating a distinct set of global application files) and/or b) are using some sort of apple script or shell scripting when opening different instances of Max to create unique global files.

@dhjdhjdhj - I know it is possible.  I was just talking with some folks who know such things..  and they specifically do it to handle audio and video processing separately.  I will get in touch with them again and find out more details.  I suspect they may have either a) installed Max more than once on the same system but in different Applications folders and/or possibly under two two admin accounts with full access privileges (thereby creating a distinct set of global application files) and/or b) are using some sort of apple script or shell scripting when opening different instances of Max to create unique global files.


When I was originally making tests, I simply just went into the applications folder and copied and pasted the max app, this worked fine with my projects, however I still have this problem where several max apps can't be opened at exactly the same time without one crashing, quite frustrating. I have to make an automator script to wait 10 seconds between each app loading which overall delays loading the full setup by about 1 minute.

p.s. here's a photo of my setup, I had a Receptor VIP with SSD on test for a few weeks but finally Max running on a mac mini was more reliable and could handle a heavier load, I could also buy 2 mac minis for less than a VIP and run them in total redundancy

Terrific --- would love to hear what you find out ---

@vichug Nope this should work in this scenario of launching multiple instance of Max.

@emmanuel, can you expand on that just a bit? I know it's possible to specify a search path in a project, but how does that affect how individual instances of Max still use the same maxpreferences.maxpref file?

@emmanuel, can you expand on that just a bit?  I know it's possible to specify a search path in a project, but how does that affect how individual instances of Max still use the same maxpreferences.maxpref file?


It doesn't, it's just that using project you have a lightweight way to have a custom search path for each project that you load in each instance of the Max application that you launch.

It seems that duplicating the Max.app (ex: Max_B.app) or by terminal : open -n /Applications/"max 6.1"/Max.app

I get an non ending posting in max window:

it woks with duplicating the whole Max 6.1 folder.

ps: i know about building apps and standalone ways but not practical in work in progress.

It seems that duplicating the Max.app (ex: Max_B.app) or by terminal : open -n /Applications/"max 6.1"/Max.app
does not work anymore
I get an non ending posting in max window:
sqlite.exec: …...

ps: i know about building apps and standalone ways but not practical in work in progress.


If one opens multiple instances of Max 7 using "open -n", is it possible to control whether each instance opens in 32-bit or 64-bit mode?

Yes, dhjdhjdhj, there is a Santa Claus. :) However, as you might expect, he's fat and doesn't actually go down your chimney.

 command does not work because there is only a single Max application to open (one Max, two modes). However.. the 

 command will launch the Unix executable within the Max package folder with the mode specified as 

To open Max in 32-bit mode, use the following in Terminal:

arch -i386 /Applications/Max.app/Contents/MacOS/Max &

To open Max in 64-bit mode, use the following in Terminal:

arch -x86_64 /Applications/Max.app/Contents/MacOS/Max &

 in each line tells the system to launch the next instance of Max without waiting for the first to quit. If you don't use it and attempt to launch a second instance, nothing will happen... until you quit - at which point, the next instance will launch automatically.

Now for the disclaimer... while I have successfully launched simultaneous instances of Max in both 32-bit and 64-bit modes, I have not tested them together. So please use with caution and don't blame me if you fuck shit up. I will report any glitches on this thread. Please do the same.

Yes, dhjdhjdhj, there is a Santa Claus.  :)   However, as you might expect, he's fat and doesn't actually go down your chimney.  

The open command does not work because there is only a single Max application to open (one Max, two modes).  However.. the arch command will launch the Unix executable within the Max package folder with the mode specified as x386 or x86_64.   In other words, instead of open -n, use arch -x386 or arch -x86_64. 

To open Max in 32-bit mode, use the following in Terminal:arch -i386 /Applications/Max.app/Contents/MacOS/Max &

To open Max in 64-bit mode, use the following in Terminal:arch -x86_64 /Applications/Max.app/Contents/MacOS/Max &

The final & in each line tells the system to launch the next instance of Max without waiting for the first to quit.  If you don't use it and attempt to launch a second instance, nothing will happen... until you quit - at which point, the next instance will launch automatically.

Now for the disclaimer...   while I have successfully launched simultaneous instances of Max in both 32-bit and 64-bit modes, I have not tested them together.   So please use with caution and don't blame me if you fuck shit up.    I will report any glitches on this thread.  Please do the same.

Oh, full testing required, of course. But thanks for the info --- independent of the 64-bit vs 32-bit mode is also the question of having multiple 64-bit versions open and whether they'll step on each other.

Another possibility I've considered is to use multiple standalone Max apps with OSC to communicate among them and some virtual audio stuff to move audio around

Oh, full testing required, of course.   But thanks for the info --- independent of the 64-bit vs 32-bit mode is also the question of having multiple 64-bit versions open and whether they'll step on each other.

Another possibility I've considered is to use multiple standalone Max apps with OSC to communicate among them and some virtual audio stuff to move audio around


Yes, I'm very interested in communicating between parallel instances of Max via udp. What sort of general testing do you think is most important?

Yes, I'm very interested in communicating between parallel instances of Max via udp.   What sort of general testing do you think is most important?


I am able to communicate between instances of 64-bit Max via udp with no trouble. The only issue is the [udpsend] object truncates float64 to float32... but that is true for any single instance of 64-bit Max too. If you need double precision, be sure to pack your values in a matrix or something similar. Not sure how this translates to audio.

I am able to communicate between instances of 64-bit Max via udp with no trouble.  The only issue is the [udpsend] object truncates float64 to float32... but that is true for any single instance of 64-bit Max too.     If you need double precision, be sure to pack your values in a matrix or something similar.  Not sure how this translates to audio.


As far as the command line method goes, start is the Windows equivalent of open, but what's the Windows equivalent of -n?


I'm having a similar issue to the one Spa reported back in 2014 - when I open a second instance of Max, the Max window is flooded with sqlite_exec_query error messages (see attached screenshot). The gist of it seems to be that some SQLite database is locked. I'm trying to test the Jamoma demo of communication between multiple instances of Max using Minuit, but it isn't working. I'm not sure if the locked database is the root of that problem, as I am able to send data between the two instances using a bare udpsend/udpreceive pair. Thought it was worth reporting anyway.

I'm having a similar issue to the one Spa reported back in 2014 - when I open a second instance of Max, the Max window is flooded with sqlite_exec_query error messages (see attached screenshot). The gist of it seems to be that some SQLite database is locked.  I'm trying to test the Jamoma demo of communication between multiple instances of Max using Minuit, but it isn't working. I'm not sure if the locked database is the root of that problem, as I am able to send data between the two instances using a bare udpsend/udpreceive pair. Thought it was worth reporting anyway.


Whoops, screen shot was too large - here you are.

Running multiple Max applications on the same machine