MIDI/OSC toggle for MSC listening?

LXConsole support and feedback
Post Reply
freadZdead
Posts: 211
Joined: Sat Jun 01, 2013 8:23 am
Location: Adelaide, Australia

MIDI/OSC toggle for MSC listening?

Post by freadZdead »

Hi Claude,

I often run shows where QLab controls LXConsole via MSC, and sometimes (when the designer fiddles with cues in a run), it would be amazing to stall LXConsole's MSC Input with a quick MIDI/OSC Toggle... In those moments, I don't want to lose ALL MIDI input (as all other hotkeys/channel faders etc) are still quite important/relevant), but JUST to suspend the MSC listening...

Ideally even in an "intelligent" manner - i.e. once the actuating of incoming MSC is switched off, the now following cue specific MSC GO commands are "buffered", so that once the "listening to MSC"-button is re-engaged, the latest/last received MSC command is then actuated.

Example:
  1. The MSC LISTENING toggle is ON
  2. QLab sends MSC GO for LX Cue 1; LXConsole Goes on LX Cue 1
  3. The MSC LISTENING toggle is switched to OFF
  4. QLab sends MSC GO for LX Cue 2; LXConsole does not go
  5. QLab sends MSC GO for LX Cue 3; LXConsole does not go
  6. QLab sends MSC GO for LX Cue 4; LXConsole does not go
  7. The MSC LISTENING toggle is switched to ON again
  8. LXConsole Goes on LX Cue 4 (to catch up)
I guess this could be helpful in tech sessions, but if this is problematic, even just the toggle without the buffering/catching up mechanism would be mighty helpful.
Cheers,

Freddy
admin
Site Admin
Posts: 1643
Joined: Mon Nov 05, 2007 1:26 am
Contact:

Post by admin »

It seems like LXConsole has reached a point where there are perhaps too many options. Adding more must be approached carefully.

The ability to separate listing for MIDI from MSC may solve your issue. But, it may also cause tearing out of hair because QLab is no longer talking to LXConsole and you can't figure out why

(because it is disabled...)

And, it is possible to envision some really nasty unintended consequences from responding to a backlog of realtime triggers at some random point in the future.

I'd like to hear from other voices that this would be a desirable and useful thing for them. It can certainly go on the list of things to be considered.

It seems the least disruptive way to implement this is through a preference. But, you can control this now by simply setting the MSC device ID to something that is not in use. This would effectively stopLXConsole from responding to MSC sent to that device ID while still leaving it responding to other MIDI messages.
freadZdead
Posts: 211
Joined: Sat Jun 01, 2013 8:23 am
Location: Adelaide, Australia

Post by freadZdead »

Yes, let's hear if anyone else is interested :).

I don't mind the idea of using a different MSC id, but there are two reasons why I think that a MIDI/OSC toggle would be preferable:

1. like you said, it is important not to cause issues for people who don't want the feature, which is why I suggest an ephemeral approach - namely, whenever the software is started or a show file is loaded, by default you ARE listening to the MSC specified in the preferences, only if you A) (actively) decide to map that MIDI function, and B) activate the MIDI button would this feature interrupt/intercept the incoming MSC, and the normal way of operating would be restored either by the toggle OFF/ON, or at the latest when the show file is reloaded or the program re-started. If it was using the manual way of going through the preferences, it would mean storing this setting until changed.

2. Going into preferences to do so (both to change the MSC id as well as to change it back) would be a relatively time consuming process, that would aggravate the issue calling for this function in the first place - namely the LX designer wanting more time in a run to change the current cue, a run that is not supposed to stop for this. Quite a few times, the designer was in the middle of a change when a pre-timed-to-music LX cue was called through QLab.

Like I said, I do think your comments are quite on the money, and that adding funtionality for some can cause issues for others, but I am not sure this could fall into that category (because of the active and ephemeral approach I am suggesting).

I do take your point about the catching-up suggestion though, and would be happy even if it meant manually catching up where necessary, if that would make things easier or safer.

Happy debating :)!
Cheers,

Freddy
Johan Söderberg
Posts: 294
Joined: Mon Sep 01, 2008 12:35 pm
Contact:

Post by Johan Söderberg »

I agree.
Adding more must be approached carefully.
This temporary switching on/off can be done in for instance Qlab and is a bit risky to put in LXConsole I think.
freadZdead
Posts: 211
Joined: Sat Jun 01, 2013 8:23 am
Location: Adelaide, Australia

Post by freadZdead »

Hi Johan,

Yes, I have since made a script that toggles by changing MSC device ID of all cues, and it does not seem to be too slow/taxing, I was merely coming from the perspective of not building complex work-arounds...

But all good!
Cheers,

Freddy
Post Reply