Museum Exhibits

[Jeremy S. Bloom]

Anyone out there using qlab regularly (or occasionally) for long term mostly unattended museam installations? I'd really love to use qlab but would love to hear other people's experiences and how they make it as fool-proof as possible for day to day operation by non audio people. Or maybe I should go a different route? 

My exhibit is an immersive surround expirence with several different "go buttons" located in different locations to trigger the start and stop of various elements.

Thanks,

Jeremy 

[Drew Dalzell]

For applications like museums I tend to turn to things like Alcorn McBride, Q-Sys, or Gilderfluke.

I've done a few with software packages like Qlab and SFX over the years and there has always come a point where the computer will decide to do something unpredictable and it causes problems. I think solutions like Qlab are wonderful when you have a reasonably skilled operator in the vicinity to make sure it's doing what it needs to do on a long term basis.

Museums tend to want equipment that can go days or weeks without being turned off and with very minimal operator involvement.

Drew

[Chris Ashworth]

As it turns out…. I have! Okay, only once, but I’ll share anyway.

I’ve been meaning to write up a blog post about it, but the short version is I built the software for an interactive installation at the Baltimore Museum of Art that is running for about 3 years. (Has been running for over a year now.)

This particular installation includes two projectors run by one QLab system on a Mac Pro (in a rack mount in the museum coat closet, which was the closest room they could put it in), and a piece of custom-built PHP hackery to allow visitors to enter text into an installed iPad in the room and then see their text projected out onto the floor of the exhibit.

The server side is here: https://github.com/Figure53/switchboard

It is a “not-amazing-but-it-works" little PHP app that provides a way to hook up outside input (e.g. web form or Twilio or whatever) into a database that QLab could then access via Script Cues to set on Titles cues.

The backend also allows the museum administrators / interns to flag the input as “approved” so that they can decide what text gets “curated” for long-term display.

The QLab workspace itself is two surfaces (one per projector) with a series of Titles cues on “tracks” that pull in randomized text from the webapp “output” URLs and animate the text gently across the floor.  The entryway has only approved text, and there’s an alcove with an iPad for the visitor to see their own text immediately (without approval), one time per entry.

It’s been helpful to reboot the machine each morning, which is something we generally recommend doing once a day for any QLab machine. Early on they had trouble with getting the security guards or front desk staff to boot the components in a reliable order — projectors on first, then the Mac, then QLab launching to ensure that OS X is detecting displays in the expected way. I believe their tech person set up a special button to turn the hardware on and off and put a built-in delay to guarantee the order of these operations without the staff having to think about it. 

QLab itself is set to auto-launch the workspace and then has a pre-wait delay on the “workspace auto-start” cue to start the exhibit going automatically when the Mac finishes booting.

Seems to have been going smoothly; it's always running when I or others drop by.  (Photo attached.)

For pure audio installations the same principles would apply; daily reboot and make sure hardware is turned on in a repeatable and reliable order. 

-C

[Charlie Richmond]

We now have well over 1.6 million audio channels in themed, theatrical, ship and fixed entertainment installations around the world using SoundMan-Server which is virtual audio control software that has been available since the AudioBox was discontinued 10 years ago and we have been installing ShowMan show control software systems (and its predecessor Stage Manager) in similar venues since 1990.

Charlie

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/8cbc2e20-7935-4296-9845-38454844ef6d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

* Charlie Richmond - http://www.RichmondSoundDesign.com

* Viber: +16047159441 Skype, LinkedIn & Twitter: charlierichmond

* facebook: charlie.richmond

* facebook.com/pages/Richmond-Sound-Design-Ltd/130195960832

* google.com/+CharlieRichmond google.com/+Richmondsounddesign

[Chris Ashworth]

My own story aside, I think Drew’s advice is generally a good place to start: QLab is most heavily used in environments with an operator, and so has been most tuned to running in those environments. When used for installations, it’s helpful to go in expecting to mind some details you didn’t have to mind in a live performance setting, and make sure your chosen tools and your circumstantial requirements will meet in a happy place.

-C

[Charlie Richmond]

My point was simply that we have had well over 2 decades of great success using generic computer platforms (properly specified and using industrial hardware in most cases, of course) in installations that are extremely demanding and last for years without operator or maintenance intervention.  Dedicated non-computer hardware is not really necessary and is usually more expensive, more difficult to maintain and becomes obsolete faster.  

If the software is designed to run on popular platforms it can easily migrate to new hardware and the equipment can be very easily maintained by IT and/or regular computer maintenance personnel.  It is also easier to update to new standards such as Dante and AVB network and communication standards without wholesale system replacement.

As always, it's usually what the customer has been told is the best and the customer is always right! ;-)

C-)

--

--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/etPan.57e2f702.6da75420.7a37%40chris-mac-pro.local.

For more options, visit https://groups.google.com/d/optout.

[luckydave]

The auto-start cue you can set in General Settings, new to v3, was added for several reasons, one of which was to support unattended installations.

For an installation like this, I'd recommend using the OS's built-in scheduling functionality to boot and shut down the computer automatically every day. Then, add an AppleScript app to the startup items for the auto-login user account, which starts QLab, opening your workspace file. Give the AppleScript a delay of a minute or so, so you can have a safe window of time for everything that needs to initialize to complete its initialization, i.e. displays booted and configured, audio devices and their drivers doing their things, all that. This way, the computer doesn't need to be touched unless something goes wrong, and a nightly reboot helps ensure you're not going to run into runaway leaks or anything like that.

And if you want that extra reliability, it wouldn't take too much to create a failover backup system that could be switched with a button or two.

--

luckydave

--
--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53
---
You received this message because you are subscribed to the Google Groups "QLab" group.

To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/eb3d2888-2428-428b-bbf4-ac65e4a9e29b%40googlegroups.com.

[Michael Sauder]

Hi folks, first time poster here.

This should already be SOP, but it's doubly so for long-term installations - be sure to disable any and all software updates, for every piece of software you can find. Simply preventing Internet access won't suffice - inevitably, a time will come where someone, somehow, intentionally or accidentally connects that computer or network to the public internet, and all those pending updates will start downloading.

Disabling internet access may conflict with a desire to have remote access to the computers. It's possible to fine-tune firewalls to allow only remote-access or VPN ports, but those configurations are easily changed and could either accidentally allow full internet (see: sudden download of updates), or completely lock you out remotely. My preferred method is to have a "utility PC" located on an internet-accessible network that also has a connection to the internal, non-internet-accessible network. You remote into the utility PC and from there remote into your desired show PC. Depending on your needs, you can go as cheap as a Raspberry Pi for this utility PC.

Oh, the reason for disabling updates is because you never know what will break. For me, the most recent version of Chrome removes an Applescript command, and I have 46 mac mini's in several installations using that command. Fortunately I had Internet access disabled to all by two of those computers. (There's a command-line option to disable Chrome updates, but it appears to be less than reliable).

Michael

Michael Sauder

Show Control Programming and Design

Email: michael...@gmail.com

Web: www.shownet.io

--

--
Change your preferences or unsubscribe here:
http://groups.google.com/group/qlab
 
Follow Figure 53 on Twitter: http://twitter.com/Figure53
---
You received this message because you are subscribed to the Google Groups "QLab" group.

To unsubscribe from this group and stop receiving emails from it, send an email to qlab+unsubscribe@googlegroups.com.

[Lists]

Hey! I was at least one of those installations.  We had okay luck with it on a roving show.  It was more reliable when we did a daily shutdown, but in the two years it was out it behaved very well.  We even used it for lighting in one exhibit for some venues where tying to the light console was too much of a pain, via a max patch, artnet interface and some MIDI.  

We usually dealt with failures by having the staff restart the machine.  Selecting very stable interfacing mattered a bit, and took some time.  As usual, we paid more for boxes with great drivers and it was better...

Charles Coes

cco...@gmail.com
www.charlescoes.com
"Man is an antientropic creature; he is a random-to-orderly arranger and tries to perceive patterns in all things." R. Murray Schafer

To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/CANrzNvxG8x6SrPDiFq2YoACTA%3DQ5tLKUWM9Nrq%3DtwG69t21ObA%40mail.gmail.com.

[Johan]

Yes I did my first just a few weeks ago.
Works like a charm!

Running a loop of lighting effects and sounds automatically using the built in weekday & time trigger.

The computer starts up with applescript reading what time it is 10 minutes before opening and then starts a worklight and so on...
At closing time it shuts down stopping all lighting effects and sound and giving the exhibitors ten minutes of extra worklight before shutting down the lightprogram (lxconsole)

It´s simple and very stable, love it! Just activate the thing and leave it waiting for the scheduled day and time.

Make sure you cleanup the computer - no napping, no auto updates, no silly sound or notifications. And use for instance applescript to make a startitem opening the exhibitionfile at computer startup.
I havent made an automatic restart of the computer, it works nicely anyway, but I guess that is a good thing to do. My applescripting skills arent the best though, so I havent dared trying ;-) I restart manually every now and then...

[ra byn (robin) taylor]

On Wednesday, September 21, 2016 at 2:51:09 PM UTC-5, Jeremy S. Bloom wrote:

Anyone out there using qlab regularly (or occasionally) for long term mostly unattended museam installations? I'd really love to use qlab but would love to hear other people's experiences and how they make it as fool-proof as possible for day to day operation by non audio people. Or maybe I should go a different route? 

My exhibit is an immersive surround expirence with several different "go buttons" located in different locations to trigger the start and stop of various elements.

Jeremy,

I support a museum that uses PC's for all their touchscreen related stuff and Brightsign players for everything else. I think we have (43) BS units running various exhibits.

It was someone on the list years ago that suggested the BS unit and they've been rock solid. If you need push buttons and LED indicators, most BS models (ignoring the very cheapest ones) have some GPIO via a db9 connector. You can have 4x4 or 8x0 or 8x0 or any combination of inputs and outputs in between. If you need more GPIO you can add a 3rd party RS232 daughter board for more. I've used the 24x24 GPIO board before. BS units will natively work with certain touchscreens (ELO being the most supported). I'm about to program an exhibit with the intent of using ELO with BS so I'll know soon how easy or difficult that is.

Qlab is 1,000,000 more flexible than a BS unit but if you just need some push buttons to play some video / audio to play, they are fine. You can set up logic between push buttons to override previous selections. In the last 5 years I've seen BS units being used more and more for exhibits. BS programming software Includes scheduling, sending and receiving UDP, scripts, etc...

One of the nice things is that you can set up units on a network and configure them to check a server based folder. If you update the files in that folder remotely, the BS units will grab them and update themselves. Picture a menu update (shown on a big monitor behind the counter) for 35,000 McDonald's stores. One upload from corporate and all the BS units grab it at midnight. Next morning the McRib is back for a limited time only without any one doing anything locally.

Since the BS runs on an SD or USB drive, you can make backups in case something goes wrong. Swap out media, reboot and you have a completely new show.

If you want specific information write me offlist.

 Best regards,

ra byn (robin)