Message Show Control

let's start this thread in english.

Message Show Control is a MIDI protocol that's designed to let devices talk each other and be synchronised.

for example "Lighting GO Cue 1.2" can be translated in MSC message (by QLab).

now how do you think i should implement such protocol? i mean does described command should load cue 1.2 in prepa register and launch GO?
do you interpret this command differently ?

you can answer in French

++
nico

Salut Nicolas,


That is exactly how I would expect the implementation, and also what you find in a lot of hardware lighting controls like the ETC Expression based lighting boards; In this manual, you can see on page 281 (Chapter 25), how they have implemented it, exactly how you described it:

www.etcconnect.com/docs/docs_downloads/m...v3.1_User_Manual.pdf


Thanks for opening this thread, I think it will help it's popularity with the QLab community !

Freddy

Oh, and the specific "translation" to SYSEX can be seen as an example on page 284...

@freddy

thank you for the links, it clarify things (especially that's there's no explicitely needed for a cue number to launch normal xfade)

how would you interpret STOP and RESUME command?
in case of pending xfade, does STOP command act like Pause in DL and RESUME unset the Pause?

++

Hey Nicolas,


re: stop/resume: yes, that would be quite sensible - although I haven't seen it been used too much in my time; But it would be definitely cool, as you could assign the trigger that pauses QLab to a MSC Cue firing this command to DL - et voilà, both QLab and DL would pause whatever they'd be doing.

re: explicity of the go command to a specific cue; While it might be a nice addition to use the Go without explicit parameters, in theatrical context (and QLab), the command most widely used would be GO <specific cue number>, as only that way you would be able to "jump around"&"set back" during rehearsals while guaranteeing synchronization between the Lighting state and the point in the show that QLab is at.

in theatrical context (and QLab), the command most widely used would be GO <specific cue number>, as only that way you would be able to "jump around"&"set back" during rehearsals

you're absolutely right.
i'll implement both version.
as DL can record cue xx.xxx i'll ask you to try to launch for example cue 2.255 (as it's a special feature of DL, i don't know if it'll work but i don't see why it shouldn't)

++

In QLab, I just set and fired a MSC Cue, set up like this:

Command Format: Lighting (general)
Command: GO
Device ID (is like MIDI Channel): 7
Q number: 2.255
Q List: 8
Q Path: 9

MIDI Monitor shows as a result the following SYSEX message in HEX:

00 F0 7F 07 02 01 01 32 2E 32 35 35 00 38 00 39 F7

, so, disected:

F0: Announces start of Sysex message
7F: Start of message
07: Device ID (would need to be set in the DL setup, like a MIDI Channel)
02: identifies Sysex as being MIDI Show Control message
01: identifies MIDI Show Control as being "Lighting"
01: GO
32: number 2
2E: decimal point (".")
32: number 2
35: number 5
35: number 5
00: delimiter
38: Q List 8
00: delimiter
39: Q Path 9
F7: stop byte

Depending if you plan to work with several cue lists in DL, you could decide to use or ignore the Q List and Q Path parameters.

Let me know if there is anything else you needed tested .

f.

well done

00 F0 7F 07 02 01 01 32 2E 32 35 35 00 38 00 39 F7

do you have the leading 00 each time ?

07: Device ID (would need to be set in the DL setup, like a MIDI Channel)

the Device ID is set when you want to send MSC to particular device.
it's range is 00-6F. (7F means broadcast to all device)
so you're right, the device ID of DL needs to be set in the setup

Depending if you plan to work with several cue lists in DL, you could decide to use or ignore the Q List and Q Path parameters.

nope there's only one Q List in DL and one Q Path, so we'll ignore them.

another concern is about the STOP/RESUME message followed by a cue number. i think in that case cue number will be ignore too and sSTOP/RESUME will act on the pending xfade regardless processed cues.
agree?

++

sl1200mk2 écrit: well done

00 F0 7F 07 02 01 01 32 2E 32 35 35 00 38 00 39 F7

do you have the leading 00 each time ?

Yes, does look like it. Unless that is MIDI Monitor showing something that isn't there (like a line number in a hex editor?)...

sl1200mk2 écrit: another concern is about the STOP/RESUME message followed by a cue number. i think in that case cue number will be ignore too and sSTOP/RESUME will act on the pending xfade regardless processed cues.
agree?

Totally - when I re-read the Expression manual, the same thoughts came to me - if a cue is not running, what good would it do to stop it; and for that matter, if a cue hasn't been paused, what good would it do to resume it;

So yes, it does make perfect sense to apply all stop and resume to a current pending xfade, and ignore all other additional data provided.

another one for that matter:

Command Format: "All types" (if you want DL to react to that and to "Lighting")
Command: STOP
Device ID: 0
Q number:
Q List:
Q Path:

produces

00 F0 7F 00 02 7F 02 F7

, so, disected:

F0: Announces start of Sysex message
7F: Start of message
00: Device ID
02: MIDI Show Control message
01: "All Types" (as opposed to "Lighting"
02: STOP
F7: stop byte


++

i get it working

by the way, Christopher from QLab confirm me this:

QLab enters "0x7F" as the first byte of all MSC messages; the 00 must be something Midi Monitor is adding

another thought about the design of this new function is that in rehearsal, you don't specificaly want the xfade to be fired when you call a particular cue.
that's why i think i'll add the MSC LOAD command to load desired cue in X2.

in brief, here's the main design.
MSC GO <Q_List> : Load desired cue in X2 and fire xfade
MSC GO : fire xfade
MSC STOP : Pause xfade if it's running otherwise nothing
MSC RESUME : re-fire xfade if it's in Pause state
MSC LOAD <Q_List> : Load desired cue in X2

++

Brilliant! So excited !

Re: Load scenario - what my métteurs en scene usually demand to do (over... and over... and over again ), is the following:
----

Scenario: We just ran a transition, say SQ 14 in sync with LX 12.3 and projection AV 5. One of the actors stumbles, or somehow the timing is not right. So the director wants to do it again.

The scene then gets set back to the previous state BEFORE the transition, i.e. silence, LX 12.1, and maybe projection AV 4.5;

Once this state is established (basically LOAD and GO of one "global" Qlab Cue BEFORE the transition), then the actors do their cue lines again, and the transition SQ 14, LX 12.3, and AV5 is run again.

---

So, the LOAD of LX12.3 would not really help here, because you will need to see the actual transition FROM LX12.1 to LX12.3;...

However, what DOES eat time is waiting for the transition time to establish LX12.1; now, I don't know if there is actually something intuitive in what either MIDI Show Control does, or what DLight does, but decades ago, there was an old hardware lighting console that had a toggle switch - either "use transition times" or "don't use transition times and establish the state without xfade"; now THAT would be something handy; I would say it does not necessarily have to be a MIDI Show Control thing; it could be just a momentary MIDI Note switch that you hold down in addition as you press your "GO" trigger in QLab to run LX12.1 - which then causes this state to be established straight away as opposed to running it's transition times...

What do you think?

Cheers,

Freddy

However, what DOES eat time is waiting for the transition time to establish LX12.1

i see what you mean, and maybe 2 solutions.
1) we can use <Q_list> paramater to select in wich "registre" we want the action to be performed.
for example if we set <Q_list> to 1, loading <Q_number> will be performed in X2(prepa) according loaded step times, if we set <Q_list> to 0, loading will be performed in X1(scene) instantly.
the limitation is to remember what's 0-1 reference...
2) use Go_Off key word in wich case <Q_number> will instantly be loaded in X1

++

Hi Nicolas,


Either solution is neat, however, they do require a change in the programmed cue on QLab side for something that you _normally_ don't want - 70% of the cases, even including rehearsals, you will need to see the actual transition _with_ the timing for synchronisation purposes.

So, for either of your suggestions to work, you would need to actively change the trigger cue in QLab (either by changing the keyword, or adding/changing the Q_List), and after you have fired it change it back again, which is not necessarily practical.

I mean, I think it would be handy for special cases to have the GO_OFF keyword (i.e. the muzzle flash in sync with a gun sound effect), but then again, so far I have always solved this in the lighting board by using 0.1 sec fades in the actual lighting cues with a follow on, so I don't think it would be a priority to have this feature.

I do think the most useful way of realising this would be a MIDI Note (or CC) trigger;

if _not_ pressed, interpret the specific GO LX 12.1 (normally) as: "LOAD LX12.1 into X2 and fire xfade"

if pressed, interpret the specific GO LX 12.1 as:
"LOAD LX12.1 into X1"

The other benefit of this would be that you could set up this new midi trigger either way, either as momentary (you hold it down if you want to fire a cue ignoring its fade),

or, if you want to show someone the differences of states by ignoring all fade times and going through it quicker, you could set up your midi trigger as a toggle switch (I use i.e. the Korg nanoKontrol/Pad series).

My two cents worth ...

I do think the most useful way of realising this would be a MIDI Note (or CC) trigger;

ok,
so let's start with simple MSC command and if you can achieve direct timing process by triggering a NoteOn (that's binded to Step+), that's perfect.

thank you for your help on the design of this function.
i'm waiting for your comments when 3.0.6_b5 will be published.

++
nico

Sounds great,


So what you are saying is - until the more elaborate "ignore the fade time when pressed" trigger/functionality is implemented in DL, I can just use the step+ and step- commands to manually step through, right?

That's definitely ok to start with, it just means that you can't operate "blind" - as in, set QLab to cover the operating screen;

But hey, I am sooo grateful for the MSC implementation, and really enjoyed being able to give my humble opionionated opinion into it all.

Will definitely give you detailed test results for the beta!


Thanks again,

Freddy