Hi Brandon,
Here’s my view on redundant systems, based on around a decade of experience building, selling, renting, and supporting redundant systems at two well known NYC area theatrical sound providers, independently as my own business, and a number of years now here at Figure 53. The long and short is that, while I understand the motivation behind wanting to link things the way you describe, I strongly advise against it. Doing so is trading a small amount of increased convenience for a much higher degree of risk.
It’s my emphatic opinion that the important thing with a redundant system is to make sure that both computers are triggered together, so that they stay in sync, but not actually directly connected to each other in any way that one of them can affect the other during the normal course of the show. In other words, you want some external trigger that sends a Go to both computers, rather than the main computer telling the backup to go. (If the main computer were triggering the backup, that means the computers are not independent, and there are a number of ways that the main computer could fail or glitch and cause problems such as incorrect triggers or a lack of sync on the backup.)
An X-Keys will not work, since it can only be connected to a single computer at once. You need something that can independently trigger both computers. Generally, the best way to do this is with some sort of MIDI trigger that can be split to both computers. At a minimum, you want one button for Go, but most users find four buttons, for Go, Panic All, Previous Cue, and Next Cue to allow the most flexibility and let you navigate through both computers’ cue lists in sync with each other.
If you have a digital console that can output MIDI from a user-defined button, such as most Yamaha and DiGiCo consoles, you can just use those as your MIDI buttons.
If not, the best solution is a dedicated MIDI device. While you can use any MIDI device to trigger QLab, the most compact solution is a remote designed for controlling QLab specifically. The best option I know of is Team Sound’s Go Button 6, which is designed specifically for controlling two computers in a redundant configuration. (Full disclosure, Sam Kusnetz, who runs Team Sound, is also a member of the support team here at Figure 53, and well known to members of this list, but Team Sound is his own independent business.) You can find out more about Team Sound on their website:
Then, of course, you need to have some way to switch the audio from one computer’s output to the other. If you have enough channels free on your console, you can just do this with a mute or patch change on your console. Otherwise, you need to add an external switcher. For analog audio, the most affordable and reliable option is Whirlwind’s AB8, which is an 8-channel A/B switch, and can be linked together for 16, 24, or more channels.
For digital audio connections like MADI, ADAT, or Dante, or for video, switching gets tricker and at times more expensive. If you’re using either of those, let us know the details of your setup, and we can offer more specific suggestions.
Hope that helps!
-Andy
—
Andy Lang
@SoundGuyAndy
sup...@figure53.com
I'm am Audio guy doing primarily corporate audio. I have a primary and backup MBP both running the free version of QLab3, at the moment. I'm trying to slave the backup to my primary, with some success.I've setup a midi network through Thunderbolt and the systems are talking back and forth. I've setup 6 "play on" cues of music and have the back up following along by MSC cues. I've been reading about global MSC, but don't fully understand it. I have individual MSC for each audio file, built into groups, so when I hit go or the Hot Key for each file it triggers the back up. Here's my question. 1. Is there an easier way then what I've done? 2. Is there a way to have a global "All Stop/Panic" button? If I press escape on my primary machine, can it stop both itself and the back up? If I move to the next cue, can the backup follow along? I don't have an external controller yet. I'm looking at getting an X-Keys XK-24 and programming it with a Play/Pause/Stop/Prev/Next buttons. Very similar to Widgeteering Q-Widget Pro. I'm using this as a train purpose. I know Q-Widget is the easiest and safest solution, but I want to understand whats happening between the machines. I havent been able to find any good tutorials for what I'm trying to do and I know its a pretty common practice in this field.
--
--
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/09b2910a-5a05-4c86-aa1e-83c8d4a41591%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Regarding your statement:
The long and short is that, while I understand the motivation behind wanting to link things the way you describe, I strongly advise against it. Doing so is trading a small amount of increased convenience for a much higher degree of risk.
I couldn't disagree more. That is, I agree that we don't want more risk of failure in a system, but I don't believe that having tighter integration between main and backup systems necesserily introduces more risk - in fact, in many ways in can result in less risk.
Current best practice seems to be this: Two independant systems, configured identically, and triggered simultaneously over USB to keep the show running in step on both machines.
While this works, it is a very delicate system. It relies on manually ensuring that both systems are at the same start position, and only permits operation that is possible via the USB controller. It also relies on manually ensuring that both machines have identical and up to date copies of the show, open to the possibility that an adjustment is made, there's no time to replicate it to the backup right away and it gets forgotten later.
A better solution would be one where the two systems are aware of each other in a master/backup configuration. They are able to maintain state across the two systems, keeping them in lockstep for any functionality performed (playback or editing). If one system goes down then the other is aware and takes over control if it didn't have it already.
This is the kind of system we already have on ETC lighting desks (and probably others, but I'm not familiar with them). A console is designated as Master or Backup upon startup, and they talk to each other over the network. Any operation performed on either console is replicated in lock-step on the other (playback, edits, you name it). If one system fails, the other picks up without a hitch.
I'm not saying this is easy to implement in the case of Qlab (there are differences between a networked lighting setup and a typical Qlab setup) but I do think this is what we should be aiming for. There is some added complexity when switching to backup, with sound cards and video outputs, but these are issues even with dual-USB control.
So it would be nice to think that one day we will have a more integrated redundancy solutionf, and are less reliant on quirky USB boxes and a lot of manual intervention.
Stephen