Loopback OSC Broadcast

[FL K]

Hi lovely people on the list and at F53,

I am trying to trigger one specific cue within a workspace each time the playhead is moved. After research, I thought the following should do the trick:

- have a "self" patch, either with localhost or 127.0.0.1 and port 53000

- send /udpReplyPort 53000 (so that any QLab replies go directly back to QLab)

- send /udpKeepAlive (to keep it alive without time-out)

- send /eventFormat "/cue/thescript/start" (so that on every event update, the specific cue with the cue number thescript is started)

- send /listen/playhead (to only react to playhead moves)

This does not seem to work, whereas if I go through an outside "mirror" like OSCulator, I can achieve what I need (but of course much less elegantly and portably).

I am of course open to alternatives to achieve the same goal, but it seems like a rather elegant use if it can be done; if it can't be done, it would be amazing to understand where my logic goes wrong.

Thanks :)!

Cheers,

Freddy

[Brent Lord]

Hi Freddy --

This is a really clever idea! There are just a few tweaks to get this working:

1. OSC Event Broadcast is expecting to reply to a network client. If you use 127.0.0.1 as your Network patch destination rather than "localhost" (which uses a special internal route in QLab), this will give QLab the destination socket on which to deliver the OSC Broadcast reply message.

2. The /eventFormat command expects an argument that contains at least one format token, otherwise it returns an error. Try setting your event format with the message /eventFormat "/workspace/#workspace_id#/cue/thescript/start" instead which should create a valid reply format.

Brent

[FL K]

Hi Brent,

Great, that worked a treat :)! One question I have, somehow, and I cannot explain how or why or when, it seems that /udpKeepAlive does not work - as in, the OSC Broadcast subsription seems to lapse;... I currently use a work around (firing that whole sequence of OSC cues every minute), but I wonder if that is avoidable/if there is anything that I am doing wrong. Or would TCP be better than UDP (if that is possible in QLab)?

BTW - what I am using it for (happy to share if anyone is interested) - I use Word Comments (but any kind of PDF annotation should do) in a Script PDF to give me Q numbers on the right, tied to words or actions in the script. These cue numbers correspond with top level timeline group cues in my main cue list. I have written a script that controls Skim (a free source forge pdf viewer with AS dictionary) to automatically jump to the corresponding cue in the script when the playhead is moved onto a cue that exists in both QLab and the script.

Very fun indeed :).

Cheers,

Freddy

[Brent Lord]

I'm not quite sure what could be making your broadcast messages lapse. I've tried a few ways, but so far have been unable to recreate it.

The "listen" command is bound to the network client that sent the message, aka the sender's IP address and port number. QLab keeps a list of UDP clients that have sent it messages, and prunes inactive UDP clients after 60 seconds of inactivity. The /udpKeepAlive 1 command opts a client out this pruning, which should keep your broadcast message subscription active indefinitely.

If you have other workspaces open at the same time that also send to 127.0.0.1, make sure all of your workspace passcodes are the same. If another workspace sends a connect message with the same client (IP + port) but with a different passcode, it could cause your broadcast messages to be silently rejected by your original workspace that is expecting the original passcode.

Brent

[FL K]

Thanks again so much Brent,

You pointed me to the mistake I made - I omitted the integer and send it without arguments! once I sent the 1 with it, it worked - even with in between closing the lid of the MacBook Pro :)!

Cheers,

Freddy