Original LXSeries Forum

Hi,

I've been handed over all techie duties for a touring show. I Don't know alot about the techie side of the theatre (usually a prop maker) so forgive my incompetence.

We are using Qlab and LX console to trigger the lighting cues for the show. I've done some research and found that using OSC is probably the best way for Qlab and LXconsole to communicate. However all the lighting cues in Qlab are set to MIDI control rather than OSC. I can't reach the previous techie so am not sure why this is.

So my question is: Can Qlab and LXconsole communicate via midi and how do you set both pieces of software up so they can do this? I want to trigger the lighting cues in Qlab then have Qlab tell LXconsole to trigger that lighting cue and send the DMX signal.

I hope this makes sense,

Thanks,

Evie

I figured it out. Thought I would post my solution in case anyone else is in the same situation as me.

Link to PDF:
https://docs.google.com/document/d/1tIr ... pYnH5c/pub

I hope this helps![/img]

The one thing you want to be careful of when using the IAC bus is that QLab either has show control disabled, or that its device ID is NOT the same as the one you to which you are addressing messages.

QLab defaults to MIDI Show Control In device ID 0. If you send a MSC Go addressed to device 0 to the IAC bus, QLab will receive that message along with other applications listening to the bus.

Where this is a problem is that you may intend to trigger LXConsole's cue 1, but find out that you are also triggering QLab's cue 1. Worse, if the cue numbers are the same, QLab will send an endless stream of MSC go messages to LXConsole.

Thanks you for your reply!

I've just ran into a problem that seems like it might be caused by the reasons you just described. Another person ran into the same issue and posted about it here: http://www.macluxpro.com/phpbb/viewtopi ... e290d67d09

I don't quite understand why Qlab would be triggered if the id number is set to zero. how does it loop back?

Is Lxconsole running slowly because I have the ID number set to 0?
Would the problem fix itself if I change the number?

Thanks so much for your help!!![/quote]

The IAC bus allows anyone to talk and anyone to listen. Any message it receives is relayed to all applications that are listening.

The loop happens when all these things are true: There is a numbered cue in QLab that sends a MSC go message. This is addressed to the same MSC cue number as the Qlab cue sending the message. The QLab MIDI cue's MIDI Destination is the IAC Bus. The MSC Device ID of the message and the "Use Device ID" in QLab's "MIDI Controls" tab of the settings are the same and "Use MIDI Show Control" is checked.

What happens is that QLab sends the go message to the IAC bus. The IAC Bus notifies everyone who is listening, including QLab. QLab gets the go message and triggers its cue. Which, in this case fires off another MSC go and the cycle continues...

You can observe this using a MIDI Monitor application and QLab running by itself. The loop sends an endless stream of MSC messages. If LXConsole is running, it will appear to freeze because it is being bombarded by all these messages. There's nothing you can do in LXConsole to get out of the loop. You have to do something in QLab to break the cycle, disable "Use MIDI Show Control", change QLab's device ID, or something.

If you start this loop going, eventually QLab seems to stop sending MSC messages --at least most of the time. But, if LXConsole is frozen by being bombarded, it is hard to wait and see if QLab just stops itself.

So, the very latest build of LXConsole (Version 5.0.3, 11007.1) adopts the same policy as has been in place for OSC "cue/n/start" messages: A MSC message triggering a cue is ignored if that cue is already running. This allows you the ability of turning off MIDI if QLab is stuck in a MSC loop. If you tried to turn off MIDI in previous builds, you would deadlock LXConsole's main thread and have to force quit.

The policy was originally created because occasionally an OSC UDP packet would get dropped and a cue would not be triggered by QLab. With the policy, it does no harm to send duplicate "cue/n/start" messages to better insure that the cue will in fact be triggered. Note that OSC uses the UDP network protocol that does not guarantee delivery of packets. This is different than MIDI and the same logic does not necessarily apply. So, the policy was never added to MSC. But, in the case described above, the solution works well.

Ahh okay, this makes sense. Thank you very much for taking the time to explain this!