Artists love to use Max to build long-term (or even permanent) artworks for exhibition. However, there are many things you should do to “harden” a patcher you are working on so that it can be used onsite. Your Max patches have to be fool-proofed and locked down!
A full discussion of setting up a Max patch into a bombproof kiosk system is worth having, but it’s a long discussion. For today, I’d like to introduce a couple of simple techniques you can use to help get your piece settled down for an installation. I’m hoping this short article serves as a starter for more conversation on the topic, so please let us know if you have questions in the blog post’s comment section.
Let’s assume that you have the machine you are going to install your piece upon, and that you are developing on it. That’s a great idea - it really pays to test out your hardware. You’ve also signed into your account on this machine so that you can save your edits. Also cool - but you don’t want this machine to eat up one of your Max authorizations once you are finished editing on it. And then you begin to worry: what if the machine doesn’t have network access when installed - will Max stop working?
The answer is - Max 7 will always run. No matter what state of authorization, expired or not, Max 7 will always open patchers and run audio and video. It’s as if the old runtime system is now built into the Max application. Take the time to test this, because you will probably want to have your piece run in Max runtime mode. To do this go to the User Accounts and Licenses page (found in the Help menu) and select Sign in as a new User, then do nothing more.
If the authorization page looks like this:
... then it means you are not signed in, and Max is running in runtime mode. I recommend this as the way to run an installation at all times. If you need to edit it after installation, you can log back in. But runtime mode is the way to go when the computer is unattended.
But wait! You can also edit in runtime mode as well - somebody might come along and edit my patcher!
This is correct. Runtime mode allows editing of Max patchers, but not saving of the edits. If the people viewing your piece have access to a mouse, or if the installation is running on a touch screen, then people are able to unlock your patcher. This is where the lockdown message to thispatcher comes in.
Max Patch
Copy patch and select New From Clipboard in Max.
The lockdown message to thispatcher does one very useful thing. It disables editing the patcher it is in. Disabling editing means you will never see the “Trial” green banner on the patcher window, nor will you see any update notices from the Cycling74 web server. In other words, it’s as good as having turned your patcher into a standalone application.
That’s it for now. Like I said, this is a huge topic, we’d love to hear about other issues you are dealing with when building installed pieces with Max 7.
I didn't know about the "lockdown" message – cool! A really important topic, thanks for bringing it up...
I recently did an installation that had several pretty complicated and resource-heavy subpatches (audio environment, video playback, camera tracking, DMX control). The "main patch" simply housed them all and booted them in sequence – each subpatch would relay its status to the main patch and give the go ahead to load the next one in sequence. Since I was at the mercy of whatever computer was provided to me by the gallery, this would make it much easier to troubleshoot during installation. Furthermore, the main patch provided a GUI of each subpatch status – critical components were constantly monitored. If a particular module crashed or did something unexpected, gallery staff could identify which one wasn't working and restart it by clicking on a button, without having to know anything about the mechanics of the patch or what the "nominal" situation should be like. AFAIK this never happened but at least when I left I could take some comfort in the fact they could do some sort of problem identification or damage control without a restart of the entire installation.
Very nice. Looking forward to more of these tips. This is a key and often ignored area that I try to stress for my students as well, so I plan to share...
I have been a victim of my own bad planning when it comes to installations, I wouldn't wish it on anyone.
@Jason Charney - that sounds very cool. I think monitoring and status updating, crash notifications and remote access are crucial to the successful running of installations. It's all "drudgery coding" too, so I believe it would be great to get some standard tools together for people to be able to just drop in.
This is nice, but I have a (silly) question... If you loadbang the lockdown message, does this mean you can never unlock/save this version again? Or is there a reverse message hidden somewhere?
Could be useful to be able to unlock the patch with a password for instance, or a hidden button somewhere, "under the doormat"... (no I'm not paranoid, THEY are just unpredictable... :)
I'm trying to get clear on the advantages of this method as opposed to creating a standalone... Thinking aloud... Having the patch operating in Runtime using lockdown is an alternative to creating a standalone. The main reason for doing this is that one can reregister at a later time if the patch needs editing. In the meantime, the lockdown message prevents a user from fiddling with the software, and defeat load bang on startup allows the creator to do further editing (with the addition of a manual "loadbang" to initialise the patch (avoiding the lockdown message) once opened). Also, I guess you don't have to worry about having to manually add missing/required files to a standalone. So, runtime/lockdown for a single, fixed installation of an app, and standalone for a general distribution of an app? I've always used the standalone method for installations, and have always found it a pretty frustrating process. Which frustration I've had to go through every time I make any changes to a patch. So it looks like you've just saved me a lot of future frustration! For which - thank you very much! Looking forward to more on installations....
Nice tip! At least we are rescued to use and from Runtime or standalone.
some simpel tips: # Let installation Max patches run for at least two day's after each other, before the opening of that event! In that way you have a stress less opening, and your beer keeps cold. :) # While building a patch you have to think over and over, how it have to, and will work and what can go wrong. # Build well constructed safety buttons (example: an INIT button) in the visible interface of the patch. So, if something is going wrong you can fix it in no time and for example go back- or forward in the installation. Works also for non-linear or random installations. # Keep a screen, keyboard and mouse hidden and connected to the running computer. It's nice to have the possibility to have direct contact to the running computer. :) # One thing i am looking into: make the running computer ready to work on it remotely. So, you can connect with the running installation computer from were you are in the world and fix/restart the patch.
Nice piece / comments thread. Some of this is news to me- so appreciated.
Just wanted to mention 2 points: 1. I saw somewhere recently about being able to trigger a restart of Max from within a patch- could be a good idea for long running, unattended works etc.
2. @Bitters last point about remote access- a very simple solution i've used is VNC. If the show PC is on the network- install VNC Client on the Show PC, and access from a VNC viewer on you home machine. Also works for hard to reach installations (just finished a piece with 5 PCs up in the ceiling- VNC was the only option, unless you wanted to get the cherry picker out!).
I guess a full expo guide could include things like: - autostart of patches on boot in diverse OS's - making sure external hardware like a soundcard is initialized - instructions to gallery personnel - proper boxing of equipment (cooling)
Yes. this is very helpful, i love the "lockdown" Yes - Autostart is king.
I need a clarify tho' - I think i am missing something reallly obvious (I hope)
you said in post #001 of this thread - "You’ve also signed into your account on this machine so that you can save your edits. Also cool – but you don’t want this machine to eat up one of your Max authorizations once you are finished editing on it."
does that mean that : Say I have my personal permanent license, currently authorized only to my main Mac. I am building a patch that now needs to be moved over to the PC that will be running it for the final museum install. Can I somehow make the PC save-able (sign in with my account??) and edit the patch ON the PC - get it running, finalize it, idiot proof it, give the keys to the client and NOT eat up a authorization?
I have been under the impression that doing the above * would * kill a authorization.
Or is that exactly how subscription works and I am being an airhead?
+1 for more of these types of guides! Professional insight on technical setups for Max/MSP installations is *very* appreciated. Any Windows and Mac programs, utilities, configurations, and general tips for long running pieces would be helpful. Starting to do more of these kinds of things, and I am eager to learn from those who have been there/done that.
Yeah you can do exactly that. Sign in on the client machine to finish the job and then sign out so that the computer is not permanently associated with your Max 7 account.
If you are developing on a bunch of machines or have multiple jobs running you may hit the 3 machine limit for authorisations on a single user license. Drop us a note immediately! We can sort you out.
Nice tips! BTW, if compiling the patch (in OSX) it is also nice to write a LaunchAgent or LaunchDaemon so that the app always remains open if it is closed manually or if it crashes. If you don't know how to write these it is nice to use tools such as Lingon.
Hey! Wow! I just tried it - put Max on the client machine, signed in to cycling74, and saving is enabled.
It appears to simply put the machine in Trial (saveable) mode. This is pure f***ing genius, and i loooooooooove this feature Cycling!!
two questions came up while doing this: 1 - I did not see a "sign out", so i used "sign in as a different user" and that seem to "sign me out" and disable the Trial mode and get out without eating up an authorization. - Is that the right way to do it? (this will be SO handy to work on stuff when i have (occasional) downtime on my weekend gig but can access their computer)
2 - If I crash Max / get a power hit / meteors destroy the building / etc. etc. while signed in this way, what happens with my Authorizations?
I recently ran an installation for half a year, and needed to auto restart the computer once in a while to clear potential problems piling up. I did not find a native way in Max to do this but used Automator (mac) to make a little app who restarted the computer when triggered. Then i used Max messages to close down max and trigger the automator app. And i got my mac to open Max and patches automatically every time i turn on my machine. That is at least one way to restart your machine by itself if you can not access it yourself. An attempt to answer your question @Mr Fold Great thread btw with lots of useful info for me. Keep up posting!!
I find for longer term/"permanent" installations it is useful to have the computer automatically reboot itself daily (using the Schedule function in Energy Saver preference in OS X). That way if something crashes or I can't get to it, at least it has a clean start every day.
hullu there- just getting into this conundrum myself. my concern is slightly different. So...we get 3 machines per authorization?
Cool. Also, i understand the OP well enough.
My installation computer is currently in a studio with no ethernet/network and it is a slightly older Mac tower with no wireless. Can i authorize it once at a spot with network and then move it back to my studio and work offline?
So I have been using a combination of shell object and MacOS Automator to load Max on boot, and to Restart show machine if any components aren't working correctly (monitored in various ways). This was all nice and happy, until the latest iteration now forces us to use a Windows 10 machine!! Any ideas?
Looks like mxj might be a go, but I am not a javascripter, and am under a deadline....
I've also seen suggestion that shell object could be rendered for Windows 10 and used in conjunction with Linux Bash shell for Windows... https://www.howtogeek.com/249966/how-to-install-and-use-the-linux-bash-shell-on-windows-10/
Anyone got this sort of automation (close / max / restart machine on condition) happening with Windows?
@Rob: Yep- totaly what I was looking for! I've started things with AutoHotKey in the mean time (and can recommend this for others in a similar boat)- but the Powershell stuff is probably a lower hurdle thanks to the included PDF of it being used for this context
I've had a max standalone running at the Hard Rock Casino in Las Vegas for over a year now.
Runs on a Mac Mini with a Blackmagic UltraStudio Mini-recorder capturing HDMI and mac's line-in for audio. It's running Teamviewer for remote troubleshooting, works like a charm, not one problem yet!
Another useful tip is to duplicate the Max application and have the second application, listen to a bang from the main patch running the installation. Using the timer object if the first patch crashes due to an error the second one can restart it via the shell object.
I've also got it so that the main patch sends an audio signal to the seconds application and if it doesn't "hear" audio for more than certain amount of time it means that the app is frozen and can't be restarted so with some zl and dict magic I get the PID of the first application and kill it and it restarts itself then.
Also a ;max realunchmax everyday at 3am is a good thing to do to. Have it in a patch for an installation in the NYC subway since I can't regularly monitor it.
