QLab and ETC light board

[Ronald Murphy]

Hello all. I am I long-time QLab user for audio and video in a local theater group. Now I want to send light cue commands to the ETC Expression light board sitting next to me and my laptop in the booth. I've read instructions on how to do this on line, and it seems straightforward. Nevertheless, it didn't work. The light board appeared to be completely ignoring my QLab commands. Attached is a PDF with several images showing the set ups on the light board and in QLab. When I fire a cue from QLab, the LED on the MidiSport interface does light up (it is recognized in the Apple Audio-Midi set up app). Can anyone help me out? Is there something else I have to set on the light board to get it to listen to the midi input?

Thank you,

Ron Murphy

[Sam Kusnetz]

Hi Ron

There are two possible reasons that are the most likely sources of your
troubles.

The first is very simply fixed: try entering a "1" in the "Q List"
field. I believe ETC requires the "Q List" field to be filled in
regardless of the fact that the Expression doesn't support multiple cue
lists.

Unfortunately the more likely reason is that most M-Audio interfaces do
not have a large enough buffer to handle MSC messages. You may be able
to get messages through slowly, but you also may not. If everything's
correctly configured and it still doesn't work, and there's an M-Audio
device in the system, that's where I usually point the finger first.

Recommended alternatives: any MOTU MIDI-only interface, any
iConnectivity interface, any ESI interface.

Cheerio
Sam

--
Sam Kusnetz | Figure 53 Field Operative
s...@figure53.com

[Sam Kusnetz]

Ron

Quick update: there's a possibility that the "Q List" works differently
than I thought, and "1" will send a cue to the A/B pair and a "2" will
send a cue to the C/D pair.

But in any case, I'm nearly sure it can't be left empty.

You'll need to do some experimenting.

Best

[Mike Post]

In addition to what Sam said, I can’t swear to it, but it looks like you’re sending a command to MIDI channel 0 and the Expression is expecting commands on channel 1. There were a few flavors about how Expression listed this and it’s hard to remember without one in front of me. the MIDI Show Control Device ID’s reading 0/1 on the console implied Send on 0 and Receive on 1.

Worth a shot...

Mike Post
mdp...@mac.com
http://mdpostdesign.com
(601) 307-8657

> --
> --
> 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/d/optout.

[Ronald Murphy]

Thank you for your replies! And so quickly too! I thought the ETC was receive/send, but I'll go back and experiment some more. And definitely put something in the Q list entry. The possibility that it's the MidiSport is troubling. Who knew? But B&H is good about returns. Thanks again.

Ron

> Subject: Re: [QLab] QLab and ETC light board
> From: mdpost...@gmail.com
> Date: Sat, 21 Feb 2015 18:16:06 -0500
> To: ql...@googlegroups.com

[Freddy Komp]

I had something similar happen ages ago to two differen ETC Express models... This was my work around, basically, you could write a script that writes raw MidiSysex cues and sees where that getsya...

because pre-google group, here the text copied in:

Snip>>>>>>>>>>>>>

So, here goes...

I have the following issue with MSC/MSysEx controlling our ETC Express 48/96 (yesyesyes, I know, ancient ;)... but it was what we could get for free, and it's reliable... ) :

I want to fire specific cues rather then just a general GO, and so I made a MSC Cue with Command "GO", Device ID "3" (which is the one I set up in the console), Q Number "56.2" and Q List "2" (which refers to the C/D Fader group on the board), Q Path empty.
When I fire the Cue, nothing happened.
So I created a MIDI SysEx Cue and typed in the raw Hex that the ETC manual prescribes, namely:
"7F 03 02 01 01 35 36 2E 32 00 32 00"

with QLab adding F0 and F7, the message, recorded in a MIDI monitor, looks like this:

"F0 7F 03 02 01 01 35 36 2E 32 00 32 00 F7"

This actually works and does fire the desired Cue. So I looked at what the other MSC Cue sends in said MIDI monitor:

"F0 7F 03 02 01 01 35 36 2E 32 00 32 F7"

As you can see, the MSC frame packets are exactly identical, except for the omitted Delimiter "00" before the ending "F7".

What's the go, is ETC not conforming to standard demanding the delimiter (as it does in its manual at  http://www.etcconnect.com/docs/docs_downloads/manuals/Express_Two-scene_Preset_v3.1_User_Manual.pdf  on page 284 (which is 298 in the pdf)? I mean, I've found a work around, but I'd rather not write 120 lighting cues in Hex if I don't have to :P. Assuming that it's not a bug (or somebody else would have mentioned it before), would there be a possibility in the preferences of either the cue or the workspace/application for a tick at "Trailing Delimiter" or something along those lines? At the moment, neither cue settings nor preferences look particularly cluttered...


cheers,

Freddy

[El Armstrong]

The ETCs have to have a non zero cue list (1 is A/B pair and 2 is C/D) and, IIRC, a non-zero path.  I would also set the MSC is to something other than 0.  

I fired thousands of cues from a MidiSport over the years, so I don't think that's the problem.  But, I could be wrong.  

Best,

El

Spel chekt by Aple. 

[Ronald Murphy]

Again, thank you all for responding. I'm anxious to get back to the theater and try again. I have high hopes for a non-zero cue list.

Ron

---

From: news...@earthlink.net

Subject: Re: [QLab] QLab and ETC light board

Date: Sat, 21 Feb 2015 23:04:10 -0700
To: ql...@googlegroups.com

[Lists]

It's also important to remember that MSC is sending a text string to fire cue numbers so if you're trying to fire cue 01 on the etc console you have to send '01' not '1'.  

Charles Coes

cco...@gmail.com
www.charlescoes.com
"Why shouldn't truth be stranger than fiction?  Fiction after all has to make sense" - Mark Twain

[Ronald Murphy]

Good lord! Did not know that. Thank you.

Ron

---

From: ccoes...@gmail.com

Subject: Re: [QLab] QLab and ETC light board

Date: Sun, 22 Feb 2015 11:34:13 -0500
To: ql...@googlegroups.com

[Richard Ingraham]

Sam, with all due respect I think this is kind of bogus information.  Or at least it's not very clear and could lead to a lot of FUD.

It's fairly well know to many that deal with these types of things on a regular basis that the M-Audio interfaces lack enough buffering to deal with large data streams, typically any large stream of MIDI System Exclusive type messages, which MSC does fall under.  However a typical MSC message is actually a very small amount of data and I don't think I've every run into buffering issues when sending simple MSC messages.  Yes of course I'm sure somewhere there is a show that is sending so many MSC commands down the MIDI pipe that it could overwhelm a MIDI interface that doesn't have enough buffering to deal with it.  But typically that issue only pops up when you're sending something that requires a large constant stream of MIDI Sys Ex commands, such as MIDI Time Code (MTC) or MIDI Sync with Song Position Pointers or the like.  I've also seen it be a problem when you have a control surface that sends large amounts of stock MIDI messages along with Sys Ex commands to update LCD displays on the control surface.  Particularly problematic in that area is surfaces that use NRPN messages for faders to gain high resolutions.  Just like MTC they can produce large streams of data that can overwhelm underperforming MIDI interfaces.

I certainly don't disagree with your recommendation for interfaces when people are buying a new unit.  And it's certainly a good policy to make all of Figure 53s customers aware of the issue.  However I think it's only fair to be realistic about what the problems really are and not just automatically assume that the MIDI interface is the issue right away when for many users they may well never run into the problem at all.  In this specific example I would doubt the M Audio interface is keeping MSC working with the ETC console unless an extreme number of messages are being sent simultaneously. 

Maybe I've just been lucky I don't know.  But I've used a lot of M Audio MIDI interfaces over the years (both with QLab and others)  and while I wouldn't say they were problem free (they actually used to be problem free in the old days when they were MIDI Man, but that's another story)  I can certainly make use of them for the simple tasks required by most shows.  I certainly don't think it's an issue to the point of being alarmist about it or telling customers they should all run out and buy a different MIDI interface. 

Having said that, if the OP did just buy it and they can return it...  I would do so.  :-)

Just for the record I've had just as many issues over the years with MOTU MIDI interfaces as I have with M Audio, probably more actually.  So I don't think any of them are perfect or bullet proof.  It's like sound cards and drivers, what works well and doesn't work well comes and goes in waves and what is the best solution right now may well suck in a few years and vice versa.

Just my opinion.

Richard Ingraham

---

From: Sam Kusnetz <s...@figure53.com>
To: ql...@googlegroups.com
Sent: Saturday, February 21, 2015 6:10 PM

Subject: Re: [QLab] QLab and ETC light board

[Alexander Taylor (Mailing List)]

Hello,

I thought I’d add my experience to the mix.  A while ago, before the days of QLab, I was using a different piece of software to trigger an Expression for a dance show.  The software would play the track, send a MSC command to the expression to run one cue for the start of the number, and another at the end of the number to blackout.  I was using a no-name simple MIDI interface because it was free and I couldn’t see any reason why it didn’t work.

All my testing went fairly well, but during the show, I would have to restart the program between every single dance number for it to be “reliable”.  If I missed one, it would not trigger the light board correctly, and I would have to start scrambling.  After the performance(s), I did some more testing with more expensive interfaces, which worked fine.  I’m now convinced that my problem was the cheap MIDI interface, which is why I don’t mess around with them anymore.

You may get away with things running fine, or you may be restarting the program/interface between every cue.  If you can get it to work at all.

Long and the short of it: yes, this problem can happen in the real world.

Alexander

[Sam Kusnetz]

Hello Richard

Sam, with all due respect I think this is kind of bogus information.  Or at least it's not very clear and could lead to a lot of FUD.

Well you are certainly entitled to your opinion, and if you're worried about fear, uncertainly, and doubt then I do think it's my responsibility to clear things up.

I can do a lot of that by quoting you:

It's fairly well known to many that deal with these types of things on a regular basis that the M-Audio interfaces lack enough buffering to deal with large data streams, typically any large stream of MIDI System Exclusive type messages, which MSC does fall under.

While it may be fairly well known to folks who have been dealing with MIDI for as long as you or I, it's certainly not common knowledge amongst folks who are tackling MIDI show control for the first time. Therefore let me again clearly state:

M-Audio MIDI interfaces lack enough buffering to deal with large data streams, including MIDI timecode, SysEx messages, and MSC.

As I said earlier, you *may* have success with MSC using an M-Audio interface, but it is known for certain that under non-extraordinary conditions, you can run into problems. Therefore to be on the safe side, we recommend against using these devices.

Yes of course I'm sure somewhere there is a show that is sending so many MSC commands down the MIDI pipe that it could overwhelm a MIDI interface that doesn't have enough buffering to deal with it.  But typically that issue only pops up when you're sending something that requires a large constant stream of MIDI Sys Ex commands, such as MIDI Time Code (MTC) or MIDI Sync with Song Position Pointers or the like.

All of this is true. Including the part about some shows overwhelming MIDI interfaces. My point is that there's no reason to use an interface with known problems when you could instead use one without known problems that costs a similar amount of money.

I certainly don't disagree with your recommendation for interfaces when people are buying a new unit.  And it's certainly a good policy to make all of Figure 53s customers aware of the issue.

Splendid.

In this specific example I would doubt the M Audio interface is keeping MSC working with the ETC console unless an extreme number of messages are being sent simultaneously.

Again, you're entitled to your doubt, and in fact I agree that it might not be the problem. This is why I first advised a little troubleshooting with the format of the MSC messages being sent.

I certainly don't think it's an issue to the point of being alarmist about it or telling customers they should all run out and buy a different MIDI interface.

Having the advantage of all the data from all of QLab's users, as well as relevant information passed to me by staff at various NYC area rental shops, I'm comfortable saying that advising people to avoid M-Audio MIDI interfaces is not alarmist, but prudent.

Best regards

[Rob Ram]

FYI I've had this fail with qlab 2 and a motu fast lane. So the brand isn't the solution necessarily..

I haven't had problems using maudio midi interfaces for midi time code / pointer etc. Which can be high through put.. In the realm of MSC. But unfortunately this is only when using them with a DAW or any software other than qlab pretty much.

I own iconnect interface and I will try to use it with qlab and give you a specific in the future.

It's easy to blame the gear. And of course it's possible that the gear doesn't work with qlab. But, that doesn't mean the gear is what's actually problematic .

There is a great chance that if qlab is being used by a small theatre not a Broadway show you can't just go around buying different gear just for qlab.

I really love qlab but I do see it happen more than once or twice where the gear is being blamed when that gear works well with everything else.

It would be like blaming the keyboard brand for the space bar not working to trigger GO when it works fine while typing in Microsoft Word.

They are entitled to their opinion but I would rather they use some resources to buy a bunch of different interfaces audio/midi etc. And then test it in house with qlab and with logic or ableton or any other software and see if the failure rate is the same.

Then when they have done the research.. And are positive it's the gear and not qlab they should put a disclaimer at the purchase point that says this software only works with RME or other high end audio / midi interfaces.

They would probably have less trouble shooting requests. And people would know ahead of time that the cost of the software is just the beginning.

I've run many shows with behringer gear and no name midi 1x1 interfaces. And it works fine.

In fact a no name midi interface ended working for the MSC cue that failed on the motu fast lane 2x2.

Again.. This is just my opinion/experience . But, disregarding just because I don't work at a rental house seems pretentious.

My suggestion is trial and error unfortunately...since it doesn't make sense that an maudio interface works on the same mac flawlessly with a DAW but not qlab. So trial and error is the only option I use.

Good luck
Robb

[Chris Ashworth]

Hi mailing list neighbors,

A few thoughts on Figure 53’s relationship to hardware advice:

Historically, especially back in the days of just me and Sean, we avoided advice altogether.  This was for two reasons:

1) Neither of us was in the field using the equipment.

2) Much of the equipment used for QLab comes in such a wide array of products that are updated with such frequency, we knew we could never keep up.

As the company has grown, we now have people on the team who DO work in the industry, and to a certain degree we lean on their experiences to report trends they’ve seen personally. Andy and Sam in particular have had occasion to glean a bunch of experience in their travels in and around the New York rental scene, and that’s often helpful information. It’s not helpful because it’s somehow “better” than what anyone else is doing, it’s just about the quantity of data you collect in that scenario. In addition, we do of course sometimes spot patterns in the thousands and thousands of support tickets we process, which is a perspective that is unavailable to folks not on the receiving end of all those support tickets.

We have also begun ever-so-slightly to flirt with the idea of doing more specific testing that is reported publicly. We’ve always attempted to do our development work on a range of old, new, weak, and powerful machines, but we know it would be helpful to put even further effort into making a more formal public resource available about the capabilities of commonly considered systems for commonly required tasks. 

All that said, we will not likely ever list “approved” devices for (at least some) categories of hardware, because there really are too many for us to test properly.

I personally have to plead ignorance in the conversation between, say, Sam and Richard, since I myself just don’t have either of their experience on this topic. I realize this makes our “official” stance a fuzzier thing than in the past, when the only official stance was that we had no comment whatsoever. So, I think this is certainly an area we could find ways to improve our communication and efforts.

Rob, as specifically regards your comments on MIDI, QLab is completely agnostic to MIDI hardware (and indeed to audio devices).  There is no difference in how it works with any MIDI device. Any difference in device behavior is entirely due to the device, not to QLab.

Thanks,

Chris

[Rob Ram]

Thanks for the input / update.

But agnostic or not. There is something unsettling about hardware that seems to work almost everything except one piece of software. And i mean that on the software side. That could be qlab or a DAW. If something worked with qlab and all DAWs but not with kontakt or mainstage I'd feel exactly the same.

But as I thought, basically, there is not  anything being tested officially. So trial and error is the only real option.

And brands shouldn't be looked at as  the solution etc. That's more like sweeping it under the rug. Especially when a motu interface for me failed and some one here is advocating purchasing that brand. I love qlab (I have multiple licenses for both the pro audio and video upgrades since version 1 because I love figure 53 so much.. I could have saved money since I don't even have time to design for theatre as much as I'd like and rarely get to use the video functions but I like to support companies that make useful gear/software.).. I love motu and maudio. I pretty much love gear in general. But I can't let myself be talked into blaming gear that works with literally everything else. Max/msp DAWs etc. I mean i can't state it enough how reliable multiple maudio interfaces have been.

I work in post production at one of the major Hollywood studios and they use maudio interfaces for their daw mixing interfacing.

Alot of Smaller theatres don't have budgets for rentals or purchasing rme gear etc.. I just feel like that being used as the answer to issues is kind of unfortunate for a lot of users.

So if that's the scenario any one finds themselves in. Do some trial and error with a borrowed piece of gear if possible.

Thanks 
Cheerio 
Robb 

[Andy Lang]

Hey Rob, and everyone else,

I'd like to add a bit of biographical detail, since I know many folks
here know my background, but some may not, including Rob. I offer this
not to brag, merely to expand upon what Chris said, and provide some
perspective on where my thoughts on particular pieces of hardware come
from.

Short version: Before working for Figure 53, for the better part of a
decade, I ran the computer departments for two of New York's best
known sound rental shops, building and supporting playback rigs over
the years running SFX 5.6, SFX 6, and all versions of QLab. I've had
my hands in more computer playback systems on more shows than all but
a handful of people in the world.

Longer version: I was the computer specialist at One Dream Sound, a
prominent rental company servicing hundreds (thousands?) of off and
off-off-Broadway theatres a year, and later at Masque Sound, one of
the leading Broadway and touring rental shops, sending out as many
Broadway and touring shows, as well as more off-Broadway and regional
shows of all scales and sizes. I've also toured as a sound engineer
with Broadway shows, and, when I'm not working here, my "night" gig is
subbing on numerous Broadway shows, including in the last few years
Anything Goes, Once, Pippin, Beautiful, and A Gentleman's Guide to
Love and Murder.

I couldn't possibly count the number of QLab and SFX rigs I sent out
over the years, but I can tell you that I oversaw a stock of hundreds
of hardware units from MOTU, Echo, M-Audio, Roland, RME, Tascam,
Edirol, iConnectivity, Weiss, Sound Devices, and more that I can't
even remember. A few years ago, I posted a photo to Instagram of the
mountain of old MOTU interfaces we retired/sold off when we reached a
point that their hardware and software glitches became too costly to
continue to support. It was more units than many smaller retailers
sell in a year.

(In fact, it's because I made such a fuss about the issues with MOTU's
support here and on the Theatre-Sound list that I got put in touch
with their controller and one of their engineers (Hi, Michael!) and
helped get a lot of fixes and changes pushed out a few years back,
along with a few other squeaky wheels.)

From 2010-2013, I personally built the QLab rigs for roughly 1/3 of
all new Broadway shows and tours in the US.

On top of that, of course, I also have the experience of
troubleshooting for countless QLab users since I joined the team here
in 2013.

So, no, I can't speak to everybody's experiences, and in the world of
modern manufacturing, anybody will have good units and bad units, and
good drivers and bugs, and some of the judgment calls on manufacturers
involve how they handle the bad ones. But I do speak with a LOT more
experience than the average user.

When I tell you I see lots of failures with a particular device or
manufacturer, that doesn't mean that there aren't folks out there
using that gear without any problem at all. It does, however, mean
that, over the last decade, I've seen enough of a pattern in the tens
of thousands of shows I've had some sort of contact with to feel
justified in warning users that they should avoid the risk if
possible.

-Andy

[Rob Ram]

again, thanks for the input. nice credits.

i give credit where credit is due.. 

 i'm glad you were instrumental in fixing the MOTU problems and now its on the ok list?

didnt work with MSC for me. but as long as its working for the broadway houses and rentals thats awesome news.

since you were able to fix the motus maybe you can have some pull with some other brands that are affordable to smaller theatres, unless figure53's intent is to only cater to touring and broadway companies you speak of. 

would be nice to know if thats the direction it's going in etc. at least for me. 

if not.. my advice to the people that work for companies that can't afford to hire you to build their rigs... is to give themselves enough time for trial and error. Because even a no name MIDI interface may suffice. even for MSC. i tested out  of desperation because the MOTU fastlane 2x2 that worked for normal MIDI CC console programming didn't seem to be able talking to the ETC. 

i mention to do trial and error, as an alternative to having to buy or hire cost prohibitive solutions. i'll just say, for me, randomly not being able to use available gear that works with all other software except qlab can be very vexing during tech. so test it out ahead of time regardless of brand. seems like pretty simple advice but its worth a mention as much as pointing out brands that supposedly work fantastic (but not for me) and brands that "dont work" and "pointing the finger" at that being a problem, that work for others on this thread except, they arent working on broadway or for other figure53 employees out on the field, etc. 

essentially it still feels sort of random to me, IMO. 

it's too bad that after all the expansion for figure53, in house testing with gear isn't on the horizon.  the software is great but isn't used in a vacuum. it has to talk to other stuff. 

thanks for the software nonetheless. because once you find the gear that you can afford/count on (brand agnostically speaking ) it makes life nice for a sound designer. 

cheers 

robb

On Saturday, February 21, 2015 at 3:03:42 PM UTC-8, Ronald Murphy wrote:

[Ronald Murphy]

Thanks to all who responded to my original question. Following the ensuing discussion about midi interfaces was quite interesting. I finally got back to the theater and, using the original midisport 1x1, set the following values in QLab:

1. For lightboard cue "2", for example, I set "Q number" to "02" (not "2").

2. Because the ETC expression cues were set to the C/D fader pairs, I set "Q list" to 2.

3. I set "Device ID" to "1" and, on the ETC, "MSC Receive" to "1".

IT WORKED! I didn't try to determine which among those changes were the critical ones; I was just happy to see it work.

Looks like this time the midisport was up to the task.

Thanks again,

Ron

---

From: murphy...@hotmail.com
To: ql...@googlegroups.com
Subject: RE: [QLab] QLab and ETC light board
Date: Sun, 22 Feb 2015 13:46:59 -0500