Synchronize two Mac with the same workspace

2,635 views
Skip to first unread message

Patrick Spadrille

unread,
May 11, 2013, 3:10:37 PM5/11/13
to ql...@googlegroups.com
For backup live purpose, i would like to synchronize two Mac running the same workspace. What i want is that firing a cue on the Mac 1 fires the same cue on the Mac 2. I have find a way to do it but it involves a lot of programming. After each cue i add a OSC cue trigering the corresponding cue on the Mac 2. It works but on the Mac 2 the next cue isn't selected. So if my Mac 1 crashes, i don't know where i was on the Mac 2. I have to look thru sometimes hundreds of cues on the mac 2 to find where i was. Not really usable in a live panic situation. I've found a workaround but it involves some more programming. I had after every cue another OSC cue that load the next cue. That way a yellow circle appears on the mac 2 and i know that's the cue i have to select on the Mac 2 if the Mac 1 crashes. Anyway, that is A LOT of programming and it seems to me that there should be an easier way to do such an obvious operation, synchronize two workspace. Any idea? Maybe a script?

Jeremy Lee

unread,
May 11, 2013, 3:23:38 PM5/11/13
to ql...@googlegroups.com
This is done all the time, and it's a lot simpler. You simply cannot have one Mac control the other, or it's not redundant.

MIDI (or in v3 maybe OSC) is the solution. Get a MIDI controller (Ducks Echo or a Midi Solutions foot switch controller) and split it into both Macs. Both macs track together with the go button. Easy...

Jeremy Lee
- A thumb is a terrible speller. Please forgive my trespasses.

On May 11, 2013, at 3:10 PM, Patrick Spadrille <patrick....@gmail.com> wrote:

For backup live purpose, i would like to synchronize two Mac running the same workspace. What i want is that firing a cue on the Mac 1 fires the same cue on the Mac 2. I have find a way to do it but it involves a lot of programming. After each cue i add a OSC cue trigering the corresponding cue on the Mac 2. It works but on the Mac 2 the next cue isn't selected. So if my Mac 1 crashes, i don't know where i was on the Mac 2. I have to look thru sometimes hundreds of cues on the mac 2 to find where i was. Not really usable in a live panic situation. I've found a workaround but it involves some more programming. I had after every cue another OSC cue that load the next cue. That way a yellow circle appears on the mac 2 and i know that's the cue i have to select on the Mac 2 if the Mac 1 crashes. Anyway, that is A LOT of programming and it seems to me that there should be an easier way to do such an obvious operation, synchronize two workspace. Any idea? Maybe a script?

--
--
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.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Waschfeld, Maik

unread,
May 11, 2013, 3:37:19 PM5/11/13
to ql...@googlegroups.com

Hi Patrick,

 

As you don’t mention QLab 3 in your post, I assume, your question is not specific to QLab-versions.

 

> For backup live purpose, i would like to synchronize two Mac running the same workspace. […] After each cue i add a OSC cue trigering the corresponding cue on the Mac 2.

 

Nearly the same here, but I used MSC (Go) instead.

Lot of programming, especially on the backup-system, not good!

 

Meanwhile I do it this way:

-          Define MIDI-Programm-Change 121 as incomming “GO” on both QLab 2-systems.

-          Use “User Defined Key” [9] on Yamahas DM1000, programmed as MIDI-Programm-Change 121.

-          Use a MIDI-cable from DM1000 to a MIDI-thru-box (MIDI Solutions here) to both system’s MIDI-In.

 

That’s it.

Both QLab-systems run in nearly perfect sync.

Everything, especially the select- and load-theme is exactly like you’d use the local GO-/SPACE-Button.

 

 

Regards...
...Maik Waschfeld

--

Patrick Spadrille

unread,
May 11, 2013, 3:44:32 PM5/11/13
to ql...@googlegroups.com
Yes it seems like an easy solution but that way, i can only use "Go" and it will stay synchronize as long as i follow the order of the cue list. But if i choose a random cue it will not be synchronized anymore. Am i wrong?

Chris Ashworth

unread,
May 11, 2013, 4:17:10 PM5/11/13
to ql...@googlegroups.com
I think there are some legit reasons for a feature where QLab would automatically send OSC commands out for every triggered cue, although I would recommend against using this as a backup mechanism.

The backup machine shouldn't require the main machine to work correctly.

FWIW, there is also an OSC command to set the playback position of a cue list, although at the moment it requires sending the unique Id of the cue, which us currently hard(er) to get if you're creating OSC commands manually.

(mobile)

On May 11, 2013, at 3:10 PM, Patrick Spadrille <patrick....@gmail.com> wrote:

Jeremy Lee

unread,
May 11, 2013, 4:25:41 PM5/11/13
to ql...@googlegroups.com
If you have a multi button remote, with buttons mapped to next/ previous, you will always be in sync. Of course if you select a cue with a mouse, you won't.

Jeremy Lee
- A thumb is a terrible speller. Please forgive my trespasses.

Patrick Spadrille

unread,
May 11, 2013, 4:33:56 PM5/11/13
to ql...@googlegroups.com
Yes multi button is a solution but i really would like to use the mouse. Scrolling cue by cue in a huge list of cues using a switch is not really fast. Christopher, can you explain how i can use MSC to set the playback position in the cue list?


Le samedi 11 mai 2013 21:10:37 UTC+2, Patrick Spadrille a écrit :

Andy Leviss

unread,
May 11, 2013, 4:45:44 PM5/11/13
to ql...@googlegroups.com
On Sat, May 11, 2013 at 4:17 PM, Chris Ashworth <ch...@figure53.com> wrote:
> I think there are some legit reasons for a feature where QLab would automatically send OSC commands out for every triggered cue, although I would recommend against using this as a backup mechanism.
>
> The backup machine shouldn't require the main machine to work correctly.

Indeed, and I'd take this a step further and put it that the main
machine should not be able to affect the backup in any way directly.
The whole point of the backup is that you don't know what failure mode
the main will have, and want to be able to immediately switch to the
backup. What happens if the main starts repeatedly triggering the
backup? Are you going to be able to pull the plug on the main fast
enough so that it stops? And then be able to get the backup back to
where it should be? If you're using MIDI, what if you think it's the
computer, and it turns out the MIDI interface has started to have a
feedback loop on the MIDI signal? (Have seen this happen once or
twice, mostly due to user error, but it can happen, and it's instant
chaos!)

On Sat, May 11, 2013 at 4:33 PM, Patrick Spadrille
<patrick....@gmail.com> wrote:
> Yes multi button is a solution but i really would like to use the mouse.
> Scrolling cue by cue in a huge list of cues using a switch is not really
> fast.

Playing Devil's Advocate, I'd argue that if your workflow during a
show involves scrolling, you should perhaps rethink your workflow. If
you need to scroll through a huge list of cues mid-show, you're taking
your attention off the show, and you're going to miss something
important sooner or later. If you can't navigate your show with Go's
and Previous/Next, and perhaps an occasional dedicated MIDI hotkey
trigger here or there in special circumstances, you'd be much better
off figuring out a way to simplify operation than to have your main
computer directly controlling the backup.

If you're talking during the tech/rehearsal process, you don't need an
online backup. It's standard practice on redundant systems to program
and rehearse off the main, then transfer that day's work over to the
backup machine and put it online for the performance. Trying to keep a
backup in sync during a rehearsal is a disaster waiting to happen at
best, and impossible at worst.

Of course, I'm biased because I manufacture such controllers (which
Jeremy so kindly mentioned earlier in this thread), but that came
second; I built them because I needed them, and existing solutions
left a lot to be desired. My background is as an engineer and designer
on off-Broadway, Broadway, and touring shows, and as the shop
technician building and supporting redundant systems. Manufacturing
came as necessity being the mother of invention and all that.

Oh, tangentially speaking, Duck's Echo will have some exciting news
coming up in the next few days. We'll be launching our full
retail/catalog site, at long, long last, and introducing a bunch of
new (or new to the web) products. In addition to what we've already
shown some of you in person or at USITT, I can tell you that we'll be
offering networked OSC versions of our current remote lineup in the
next couple of weeks (including power-over-ethernet ability!), and
some even more incredible new OSC gear for redundant systems later in
the summer. (Which we will possibly be giving a slight tease of when
the website launches, to whet your appetites.)

Best of luck,
Andy

Patrick Spadrille

unread,
May 11, 2013, 5:01:06 PM5/11/13
to ql...@googlegroups.com
I just discovered you products. Seems interesting. Really pricey but interesting. But at the beginning of your message you said that Midi interface could cause problem too. So what difference offer your product? Isn't it a midi controller?


Le samedi 11 mai 2013 21:10:37 UTC+2, Patrick Spadrille a écrit :

Andy Leviss

unread,
May 11, 2013, 5:28:37 PM5/11/13
to ql...@googlegroups.com
On Sat, May 11, 2013 at 5:01 PM, Patrick Spadrille
<patrick....@gmail.com> wrote:
> I just discovered you products. Seems interesting. Really pricey but
> interesting.

Well, they're not cheap, but compared to the price of building a
similarly featured custom solution, they're pretty reasonable ;-)

> But at the beginning of your message you said that Midi
> interface could cause problem too. So what difference offer your product?
> Isn't it a midi controller?

Well, the short answer, any piece of gear can fail, the goal is always
going to be to reduce the chance of failure, and contain the results
of said failure, if it happens.

The more specific answer, what I was referring to specifically was a
USB or Firewire interface with MIDI inputs, which is what you'd use to
connect a MIDI-based remote to the computer. (We also manufacture
direct USB versions, but those only work for single-computer setups,
since you can't split USB. We've looked at doing a dual-USB version,
but with OSC coming out, are not sure about releasing it, since the
cost vs the OSC version would probably make it not worthwhile, and the
OSC versions will be able to address two workspaces simultaneously.)

What I've seen happen is a MIDI device accidentally set to echo the
incoming MIDI commands back to the output; if your MIDI setup is
cabled to then return this output back to the input of the computer,
suddenly you get a feedback loop of that MIDI message over and over
again.

I'm not saying this is a common problem, it's not at all, and requires
very particular combinations of MIDI routing and device configuration
to make it happen. I'm just offering it as an example of one of the
ways redundant systems can fail. The idea in general is to minimize
single points of failure, and while some single point of failure will
be unavoidable, to make sure it's something you can easily contain or
work around, as well as something that's very, very unlikely to fail.

The computer running QLab has thousands of variables that could cause
it to fail. (Again, it's not likely to happen frequently, but when it
does happen, you want to be prepared.) By moving to a MIDI
thru/splitter of some type, and a dedicated MIDI remote, you move that
point of failure to a couple dedicated devices that are optimized for
exactly what you'e doing with them, and have few if any options you
can change that could cause them to behave unpredictably. (Or, in this
exciting new world of QLab 3, translate this to potentially read
"moving to a simple unmanaged ethernet switch and a dedicated OSC
remote.)

And in the rare case that your main computer fails, and your
triggering system fails, you can still disconnect the remote and
trigger the backup with mouse or keyboard. But at that point, so many
failures have happened consecutively that you may be better off
running out of the theatre and grabbing cover before it starts raining
frogs or something on you!

Does that make a little more sense?

-Andy

P.S.- While the lowest priced options we offer have only changed a
little bit, we've been streamlining and reconfiguring our MIDI
controller product line here at Duck's Echo, so some of our "fancier"
options are now a bit more affordable. This will all be on the new
site when it launches next week.

Basically, we've discontinued the metal-enclosure MR-6, and now offer
all our models in the same ABS body as the MR-4. They start at $315
for USB, and then you can mix and match to add options as needed: $20
for "standard" MIDI instead of USB, $60 for two additional buttons,
and $60 for the external footswitch/go connection. Even fully
configured, the equivalent of the old MR-6's functionality is only
$455, instead of $525 with the old version.

Patrick Spadrille

unread,
May 11, 2013, 5:35:12 PM5/11/13
to ql...@googlegroups.com
Thank you for all those details. I will see you website next week. 


Le samedi 11 mai 2013 21:10:37 UTC+2, Patrick Spadrille a écrit :
Reply all
Reply to author
Forward
0 new messages