[QLab] ETC Ion Lighting Console triggering QLab

[Jeremy Goldenberg]

Hi all,
So I am trying to get my ETC Ion Lighting Control console to trigger
my video cues in QLab 2.3.5. I have a MIDI monitor program sniffing
my MIDI Input and I am getting the MSC commands into my computer but
nothing is happening in QLab. As I understand it if I want a cue to
fire with Ion cue 30 that QLab cue must be numbered 30.00. Is this
correct? The following is the SysEx command that my sniffer detected
and it seems to correspond with what I am looking for:
00 F0 7F 01 02 01 01 33 30 00 31 F7 | 30 1 |

It seems to me as though the MIDI command is getting into my computer
but isn't making it into QLab.

Anyone have any suggestions?

Thanks!
Jeremy
________________________________________________________
WHEN REPLYING, PLEASE QUOTE ONLY WHAT YOU NEED. Thanks!
Change your preferences or unsubscribe here:
http://lists.figure53.com/listinfo.cgi/qlab-figure53.com
Follow Figure 53 on Twitter here: http://twitter.com/Figure53

[Rich Walsh]

On 5 Oct 2011, at 17:51, Jeremy Goldenberg wrote:

> So I am trying to get my ETC Ion Lighting Control console to trigger
> my video cues in QLab 2.3.5. I have a MIDI monitor program sniffing
> my MIDI Input and I am getting the MSC commands into my computer but
> nothing is happening in QLab. As I understand it if I want a cue to
> fire with Ion cue 30 that QLab cue must be numbered 30.00. Is this
> correct? The following is the SysEx command that my sniffer detected
> and it seems to correspond with what I am looking for:
> 00 F0 7F 01 02 01 01 33 30 00 31 F7 | 30 1 |
>
> It seems to me as though the MIDI command is getting into my computer
> but isn't making it into QLab.

The MSC you've captured is for GO cue 30 on cuelist 1 of device ID 1 in the Lighting group - see here:

http://www.etcconnect.com/community/wikis/products/understanding-the-msc-commands-eos-family-receives-transmits.aspx

A quick bit of testing and a look at the manual suggests that QLab ignores the cuelist variable. If you number your cue "30" it should fire with this MSC command; "30.00" is NOT the same as "30". Assuming of course you have the correct device ID set...

Rich

[Christopher Ashworth]

Just to copy-n-paste the answer Sean sent via our support desk:

"The first troubleshooting step I'd take would be to open up the workspace preferences and select the Remote Control page. Make sure "Use MIDI Show Control" is checked, and that the device ID is correct for what the Ion is sending out. It looks like the Ion's messages are intended for device ID 1, and QLab defaults to 0, so that may be the reason it's not responding.

Also, I'd try setting the cue number to "30" instead of "30.00". It looks like the Ion is just transmitting Q 30, Q_List 1, so QLab should be looking for a cue numbered "30"."

-C

[Paul Gotch]

On Wed, Oct 05, 2011 at 12:51:49PM -0400, Jeremy Goldenberg wrote:
> Hi all,
> So I am trying to get my ETC Ion Lighting Control console to trigger
> my video cues in QLab 2.3.5.

The below is the definitive list of steps you need to get an Ion to
talk to QLab and QLab to talk to an Ion.

Can someone put this on the wiki?

1) Connect hardware. With the USB interface the obvious lable applies
In->Out, Out->In

2) Make sure that the MIDI ports are enabled in the Local/IO section of
the settings menu outside the Ion software. Make a note of the ACN
channel numbers, these range from 1-32 and the Ion should default to 1.

3) Start the Ion software and go to the 'Show' settings. Go to the
remote settings then:

- Make sure the ACN MIDI Tx ID matches the ID configured in the
Local/IO section outside the software.

- Enable MSC Rx if you want control the desk from outside and MSC Tx if
you want to control something else from the desk.

- Configure the channel numbers for Rx and Tx. These actually configure
the MSC 'Device ID' and range from 0-126, 127 is the all-call ie
broadcast ID.

- If you want to control QLab from the Ion then make sure that the MIDI
Show control is enabled in the Remote section of the workspace
prefernces and that the device ID configured in QLab matches that
configured in the Ion.

- I *think* if you want GO's with cue numbers attached then you need to
enable MIDI String Tx as well otherwise the cue numbers don't get
attached to the MSC GO command but I'm not sure.

- Cue numbers in QLab must exactly match the Cure numbers in the Ion
that is to say 1 and 1.00 are *not* the same.

-p
--
Paul Gotch
--------------------------------------------------------------------

[Charlie Richmond]

On Wed, Oct 5, 2011 at 10:56, Paul Gotch <paulg...@chiark.greenend.org.uk> wrote:

- Cue numbers in QLab must exactly match the Cure numbers in the Ion
 that is to say 1 and 1.00 are *not* the same.

Note that this is not very intuitive and neither is not having it support cue list (if that is true) and perhaps Christopher should consider changing it to conform with this suggestion from the MSC spec (from http://www.richmondsounddesign.com/docs/midi-show-control-specification.pdf):

 

Q_number, Q_list and Q_path are expressed as ASCII numbers 0-9

(encoded as 30H-39H) with the ASCII decimal point character

(2EH) used to delineate subsections. In the example above, cue

235.6 list 36.6 path 59 would be represented by the hex data:

32 33 35 2E 36 00 33 36 2E 36 00 35 39 F7

Decimal points should be separated by at least one digit, but

Controlled Devices should accommodate the error of sending

two or more decimal points together. Any number of decimal point

delineated subsections may be used and any number of digits may

be used in each subsection except that the length of the data

must not cause the total length of the MIDI Show Control

message to exceed 128 bytes.

Controlled Devices which do not support Q_list (or Q_path)

data must detect the 00H byte immediately after the Q_number (or

Q_list) data and then discard all data until F7H is detected.

Likewise, Controlled Devices which do not support the received

number of decimal point delineated subsections, the

received number of digits in a subsection or the total number of

received characters in any field must handle the data received in

a predictable and logical manner.

Controlled Devices which support Q_list and/or Q_path will

normally default to the current or base Q_list and Q_path if

these fields are not sent with Q_number.

[Christopher Ashworth]

On Oct 5, 2011, at 2:24 PM, Charlie Richmond wrote:
>
> Note that this is not very intuitive

QLab "numbers" are strings, just like MSC commands. QLab does not attempt to be clever about interpreting them (or the MSC Q_number) as a "real" number, hence the need for an exact match. It may be useful to interpret incoming MSC commands and translate decimal points with trailing zeros to the same "number" without the trailing zeros.

I would note that the spec you quoted, it says:

"Controlled Devices which do not support the received number of decimal point delineated subsections, the received number of digits in a subsection or the total number of received characters in any field must handle the data received in a predictable and logical manner."

Which is, I'll point out, exactly what QLab does.

On Oct 5, 2011, at 2:24 PM, Charlie Richmond wrote:
> neither is not having it support cue list (if that is true)

It is true. Supporting the cue list doesn't make sense in QLab; cue lists are just cues, and all cue numbers are unique. Thus adding a Q_list paramater to an MSC command can provide no additional information in the world of QLab. This is why it ignores that parameter.

-C

[Charlie Richmond]

On Wed, Oct 5, 2011 at 11:49, Christopher Ashworth <ch...@figure53.com> wrote:

On Oct 5, 2011, at 2:24 PM, Charlie Richmond wrote:
>
> Note that this is not very intuitive

QLab "numbers" are strings, just like MSC commands.  QLab does not attempt to be clever about interpreting them (or the MSC Q_number) as a "real" number, hence the need for an exact match.  It may be useful to interpret incoming MSC commands and translate decimal points with trailing zeros to the same "number" without the trailing zeros.

I would note that the spec you quoted, it says:

"Controlled Devices which do not support the received number of decimal point delineated subsections, the received number of digits in a subsection or the total number of received characters in any field must handle the data received in a predictable and logical manner."

Which is, I'll point out, exactly what QLab does.

My apologies for thinking that Cue 1.00 is the same as Cue 1.  In my book and in mathematics they are the same ;-)

 

On Oct 5, 2011, at 2:24 PM, Charlie Richmond wrote:
>  neither is not having it support cue list (if that is true)

It is true.  Supporting the cue list doesn't make sense in QLab; cue lists are just cues, and all cue numbers are unique.  Thus adding a Q_list paramater to an MSC command can provide no additional information in the world of QLab.  This is why it ignores that parameter.

Thank your for your feedback.  I'm just trying to be helpful.  I thought QLab had the equivalent of Cue Lists but just called them something else.  My bad.

Charlie

[Christopher Ashworth]

On Oct 5, 2011, at 3:01 PM, Charlie Richmond wrote:
>
> My apologies for thinking that Cue 1.00 is the same as Cue 1. In my book and in mathematics they are the same ;-)

"predictable and logical" does not imply interpreting data in the way you've described. Exact string matches are quite predictable and logical. Are they the best behavior? May not be, because of the way some light desks behave. But I always prefer to lean in the direction of "software shouldn't try to be clever", which is the impetus for QLab's current behavior.

[Christopher Ashworth]

On Oct 5, 2011, at 1:56 PM, Paul Gotch wrote:
>
> The below is the definitive list of steps you need to get an Ion to
> talk to QLab and QLab to talk to an Ion.
>
> Can someone put this on the wiki?

Just added it:

http://wiki.figure53.com/QLab+Hints+and+Tips#x-Controlling QLab using MSC from an ETC ION

Thanks very much Paul!

-Chris

[Charlie Richmond]

On Wed, Oct 5, 2011 at 12:16, Christopher Ashworth <ch...@figure53.com> wrote:

"predictable and logical" does not imply interpreting data in the way you've described.  Exact string matches are quite predictable and logical.  Are they the best behavior?  May not be, because of the way some light desks behave.  But I always prefer to lean in the direction of "software shouldn't try to be clever", which is the impetus for QLab's current behavior.

I understand this impetus.  Where we ran into trouble with this logic was that it became extremely difficult to come up with logic that described what the natural cue order might be for these types of cue numbers. For example:

1

1.0

1.00

1.000

and other variants that include any number of trailing zeros and that's why we decided to disallow them.

Charlie