salvadorpsartek

I'm running a few recent minimacs (Mountain lion 10.8.3) for an installation.

At the start I run an application made with automator, which adjusts volumes etc and open the patch win runtime.

My problem is that if I don't quit max runtime properly before turning off the computer, when re-starting the computer, and opening max runtime via the automator application, it will open 2 instancies of the same patch.

I will need to use the programming to turn off and on the minimacs so I won't be able to quit runtime before I turn off the macs.

Did anyone experience a problem like this? I unchecked the box "Reopen windows when logging back in" that appears when I turn off the mac, and checked the box "close all window when quitting an app" in the general settings. It seems this happens only with max runtime.

Maybe there's a feature in max that allows to close every other patch when a patch is launched?

Hello,
I'm running a few recent minimacs (Mountain lion 10.8.3) for an installation.
At the start I run an application made with automator, which adjusts volumes etc and open the patch win runtime.
My problem is that if I don't quit max runtime properly before turning off the computer, when re-starting the computer, and opening max runtime via the automator application, it will open 2 instancies of the same patch.
I will need to use the programming to turn off and on the minimacs so I won't be able to quit runtime before I turn off the macs.

osx-10-8-3-automatic-patch-re-opening

So, are you saying that you need to shutdown the computer via max and so it can not quit properly? Or Automator is responsible for shutting the runtime down, but the runtime doesn't get closed via automator? Is the quit/shutdown time variable (or there is another reason you can't get the runtime to quit out itself)? Just curious...

In any case, it *might* be possible to achieve what you need by using a runtime patch that loads another patch via the [pcontrol] 'loadunique' command, but unfortunately this may not be guaranteed to prevent the very same problem occurring in the patch that contains pcontrol.

So, are you saying that you need to shutdown the computer via max and so it can not quit properly? Or Automator is responsible for shutting the runtime down, but the runtime doesn't get closed via automator? Is the quit/shutdown time variable (or there is another reason you can't get the runtime to quit out itself)? Just curious... 

In any case, it *might* be possible to achieve what you need by using a runtime patch that loads another patch via the [pcontrol] 'loadunique' command, but unfortunately this may not be guaranteed to prevent the very same problem occurring in the patch that contains pcontrol.


I passed everything under max 6 and it seems to be solved now.

yes,
That was my problem with max 5.
I passed everything under max 6 and it seems to be solved now.
thanks for your advice,
J.


Hi, any news on preventing Max5 to reopen the last patch and all its windows?

Is there any other system preferences option in OSX 10.8 to prevent this?

I'm kind of stuck, since I've been tracking a bug that makes Max5 crash when memory is low and many windows are opened. I can now successfully reproduce this, and am stuck in a loop: Max opens, reopens all patchers, crashes, back to start.

Hi, any news on preventing Max5 to reopen the last patch and all its windows?
Is there any other system preferences option in OSX 10.8 to prevent this?

I'm kind of stuck, since I've been tracking a bug that makes Max5 crash when memory is low and many windows are opened.  I can now successfully reproduce this, and am stuck in a loop: Max opens, reopens all patchers, crashes, back to start.

http://osxdaily.com/2011/08/01/turn-off-resume-per-app-in-mac-os-x-lion/

Maybe deleting ~/Library/Saved Application State/com.cycling74*

There may be usefull hints here:
http://osxdaily.com/2011/08/01/turn-off-resume-per-app-in-mac-os-x-lion/
or not…

I think I did this once by making that "saved application state folder" be read only so that apps could not actually save their state.

Another possibility is to temporarily rename the root folder where your Max patchers live. Use a bash script that would rename the folder to something else, reopen max, and then revert the folder name

Ah, that's great to know!, thanks Patrick and dhj!

FWIW, I got out of the loop by removing the big patch completely (renaming the main patch and some abstractions wasn't enough, it was opened under the new name, and the abstractions, too).

I'll post them with the out-of-memory bug in a separate thread.

Osx 10.8.3 & Automatic patch re-opening