permanent installation: advice on stability needed
hi forum,
lately i have used max/msp building a permanent installation for the danish workers museum. it is a 15minutes audio/video/light story. so linear and non-interactive.
i am a first time max user, but everything works fine and i am very happy about the way max performs :) but now, when i am about to wrap up the project i would like to have some advice on the best setup for high stability and low (preferably no) maintenance.
basically my setup is this:
- one mac mini running 6 channels of audio and a 2400x600 pixel video stream through a triple head to go.
- max is also in charge of MIDI sequencing 32 DMX channels for light control through an enttec DMX USB PRO device.
- i have one custom built control panel (arduino based) for user interaction. the arduino is connected via USB over ethernet and runs standard firmata firmware.
- before playback i switch the video projectors on over ethernet using telnet protocol. after playback they are switched off again.
- i would like the installation computer + control panel to just stay online at all times.
my considerations are these:
max seems rock solid. no crashes at all :) but still i am worried that having an application running for (in theory) several years and possible memory leaks. after all, the media files i am playing are huge. so my initial idea has been to have a little processing/java sketch running taking care of all the communication with the beamers and the control panel, launching a max/msp application at the correct time. the max application will then close it self once the timeline has been played. this way the actual media heavy application will only play once every time it is launched, and somehow this seems more reliable to me?
but i am thinking i might be making things more complicated than they need to be?
would it be safe to have max handle all the communication and run the same program / large media files for ages?
i am worried that processing<>max communication might turn out problematic... perhaps i should make the daemon in max in stead? can max launch other max applications?
any suggestions on program interactions? how will my control daemon know when the max application is done playing? OSC?
any thoughts are greatly appreciated!
/j
I don't like the idea of wasting power so I have my Mac's energy saver set to never sleep and the scheduler will shut down and restart the mac before the exhibit opens and after it closes. The patch, a standalone, is launched by the user startup items.
I figure this also bypasses any possible memory leaks and help keep things running smoothly. That way I also know that if it ever crashes, or shuts down due to power failure, the computer can simply be restarted with the push of a button. Saves me money on a UPS too.
cap10subtext: i see. i wasn't clear on how to installation will be run.
the installation is non-interactive, but it is a 15 minute story line which is triggered by a museum worker a few times a day, when the audience is there. so there is no fixed start times, and i would like to avoid having the museum workers and guests wait for the computer booting.
but i guess it would be a good idea to turn the computer off at least at night!
I've set up interactive PC installations that have run for weeks or a month or two in a gallery. I was convinced my app was fairly stable before the shows but after 2 or 3 days running non-stop, problems did crop up (e.g., the USB camera might freeze up). I set up the app to run automatically when logging into a passwordless demo account, however, so I simply had the curators either log out or shutdown each night and log back in in the morning and this seemed to work fairly well over the long haul. This did lead to a problem in a public space of chidlren sometimes finding and playing with the keyboard and mouse. =:O
One problem had nothing to do with Max or the PC - in some locations, sometimes someone would tire of the constant audio and turn the sound down too low. This wasn't too uncommon in venues that weren't used interactive art.
damblk: luckily the computer i will set up, is safe in a server room. so no-one will turn volume up/down or fiddle with keyboard / mouse :)
after thinking about things and the feedback i have gotten here, i realize i have been making this too complex for myself (i keep forgetting the programming mantra: first i make it stupid, THEN i make it clever)
if i set up a scheduler to turn the computer off every night, i only need to make a program / setup stable enough to run for a day and a few showings. this seems reasonable with just 1 max patch doing everything.
thanks guys!
I did a couple of Max installation running during monthes and one even during 5 years now.
Test, test and test again! Ask a 3 years old kid to play with the mouse/keyboard, you can be sure he will try things you'd never think about ;-)
You should reboot sometimes, once a day or once a week, depending on your patch.
Make sure your Mac is set to server mode, so it will restart after a power failure.
Have a look at http://www.peterborgapps.com/lingon/ which is great to monitor apps and make sure they restart after a crash.
Speaking about crashes, I'd disable the "Send a report…" window which normally appears after an App crashes: you can do that with the free (?) Onyx utility.
To test a Max crash, use this message: ; max crash.
You may need to build an AppleScript (or an automator) App to delay the launch of your patch (or better your standalone) at reboot: some external hardware (like some M-Audio or Presonus sound cards) need some time to be made available by the OS ; Max may start to fast and won't have access to them. Just test to check if it's usefull.
p
thanks patrick! great advice!
"You may need to build an AppleScript (or an automator) App to delay the launch of your patch (or better your standalone) at reboot: some external hardware (like some M-Audio or Presonus sound cards) need some time to be made available by the OS ; Max may start to fast and won't have access to them."
Good point. I recall now having to add a DELAY object or two in the patches to avoid certain initialization timing issues.
"if i set up a scheduler to turn the computer off every night, i only need to make a program / setup stable enough to run for a day and a few showings. this seems reasonable with just 1 max patch doing everything."
Sounds good. Yes, simple is better.
Hi everybody,
It's comforting to know that I'm not alone in encountering these common issues, and I appreciate everyone sharing their insights.
Recently, I developed a standalone app for a museum, which involves playing back a one-hour movie along with real-time jitter processing. Here's a summary of my setup:
I utilize mc.sfplay~ to loop an 8-channel WAV file (approximately 2.5GB, 1 hour in duration).
It sends "time_ms $1" messages to jit.movie to synchronize the playback, which has been tested multiple times successfully.
There's additional jitter real-time programming for interaction.
A scheduler is set to automatically stop/start jit.world and dac~.
We're using the "MHlink[47735]" (Metric Halo 2882) sound card to handle the multi-channel output, which seemed fine during setup.
we use Mac mini M1, fps can reach up to 60, not bad.
However, we're encountering a problem where the sound output and the movie aren't synced on subsequent days. The temporary solution has been to manually toggle the patch off/on every morning.
The current startup procedure we're advising staff is as follows:
Power off the amp.
Power off the Metric Halo 2882 sound card.
Toggle off a UI in the patch (stopping jit.world and dsp~).
Power on the amp.
Power on the Metric Halo 2882 sound card.
Select a specific output "MHlink[47735]" in the patch's DSP setup.
Toggle on a UI in the patch (enabling jit.world and dsp~).
Some uncertainties that might be causing the lagging issue:
Memory leak?
Staff not following the startup sequence correctly?
Powering off the sound card before turning off dsp~?
Turning on dsp~ before powering on the sound card?
Selecting sound output but forgetting to restart dsp~?
Potential issue between mc.sfplay~ and jit.movie?
I'd appreciate any insights or suggestions to address this issue. Looking forward to your reply.
Jent Zheng
Best regards
powering audio interface Off/On makes no sense.
the opposite - it troubles running max application.
You set audio settings once, and it should be auto-loaded for subsequent app starts,
if you take care that audio interface is powered on before max app starts.
sfplay~ needs no mc. to play 8 files.
You have to restart mac and start your app
scheduled, as needed, once per day for example.
Some thoughts:
I don't own a Metric Halo, but does turning off DSP in Max make an audible sound? If not, you may not need to turn off the soundcard.Also, if the museum isn't open 24/7, you can turn off the computer every night, just to avoid possible memory leaks.
try different video codecs to see if the issue lies there
why not embed the audio in the movie and use mc.jit.movie instead?
More general thoughts regarding permanent installations:
https://openframeworks.cc/ofBook/chapters/installation_up_4evr_macosx.html this i a slightly old tutorial for openFrameworks with some good advice for optimizing and troubleshooting
I also suggest implementing power sequencing devices like these: https://www.furmanpower.com/power-sequencing/ so you don't have to worry about museum operators to learn (and regularly forget!) power on/off sequences.
@SOURCE AUDIO @LSKA thanks for the quick reply!
Powering the audio interface Off/On makes no sense.
I never knew the audio interface has a power button, and I assumed it should always be connected when writing my patch alone, until I reached the venue. And yes, we do care about the audio interface.
sfplay~ needs no MC to play 8 files. Why not embed the audio in the movie and use mc.jit.movie~ instead?
I was about to embed 8 channels in the movie, but mc.jit.movie~ seems not yet to support multi-channel playback (from ROB RAMIREZ). That's why I merged 8 files into a single WAV then used mc.sfplay~ to playback the sound and also drive the jit.movie playback.
Try different video codecs to see if the issue lies there.
The movie was in 1920x1080@fps30, encoded in H.264 format, and it was converted to ProRes422. I also tried using HAP, but those made no difference to me, and I chose ProRes422 as my final decision.
And thanks @lska again for the additional articles :-).
Hi, 14 years ago I did a six months installation, just audio (16 channels) , which was located in a public space, with control logic complex enough to ensure total playback difference for at least an hour and more.
After a lot of tests I ended up choosing this solution:
2 timer plugs:
Plug 1 power up the amplifiers (first in the day, let say at 7.50 am)
Plug 2 power up the audio cards (I used two, because at that time whas not so cheap to find a 16 channels Audio Card) at 8 am
Mac mini with the Max Patch in the startup Items (with autostart at 8.10 am, now in Ventura you need to setup the autostart through terminal)
Max patch with delay 10 sec on load and then audio on and play
Max patch stop at the end of the day and then shut down with the amazing external "curtains" by Jeremy Bernstein.
Power down Amplifiers first (via the timer plug)
Power Down the audio cards.
This worked quite well, except for some crashes due to power losses!
Two more things:
To play 8 channels you can simply use sfplay~ 8
Regarding the video: why if you encoded in H264, then you convert it to ProRES 422? It becomes much heavier to manage, and in my experience H264 is more than sufficient for excellent and fluid playback.