Using OSC with AppleScript

[Rich Walsh]

I’ve hit a dead end in my understanding of OSC. Thanks to Mic’s work on animated eyeballs I can see how to use the response to an OSC “query” as a variable in another OSC command, but I can’t work out how to use a response in a more general way…

For example, something like /cue/{cue_number}/maxTimeInCueSequence looks quite interesting and useful, but not if I can’t get the answer into AppleScript to work with.

I know how to use nc to send commands to QLab, but I haven’t found a simple solution to listen for the reply yet. Is there one? Do I need to use something like Python to do this – which is a little bit beyond my knowledge at the moment?

It’d be a shame to have to use a dummy cue and do things like "/cue/999/preWait # /cue/1/maxTimeInCueSequence #”, and then query cue 999.

Has anyone written a neat little shell script that can send an arbitrary OSC command to QLab and parse the answer? Does QLab even reply to external queries without going through a whole handshake routine?

Thanks.

Rich

[Chris Ashworth]

I can at least answer the last question:

Depends on what you mean by handshake routine, but if you are using UDP QLab will still reply to external queries and since UDP is connectionless it just sends the reply to port 53001 on the IP address it got the request from.

Thus, if you have something that can parse the reply you can use it that way.

One additional feature that could help here is the new ability (in version 4) to specify a reply format.  By default, it looks like this:

http://figure53.com/docs/qlab/v4/scripting/osc-dictionary-v4/#reply-format

But the Application Methods :

http://figure53.com/docs/qlab/v4/scripting/osc-dictionary-v4/#application-methods

includes the command /replyFormat which you can use to set a custom format for your client.

You can use this to simplify the kid of reply you get back, so that if you don’t want to e.g. parse JSON you can set it up to just send back ONLY the data of the reply and no other information. (it’s still OSC though; there’s no text-only protocol at this time)

-C

[Rich Walsh]

I think when you first introduced OSC I came away with the impression that you had to /connect {passcode_string} before something outside of QLab could talk to it – rather than just send orders – and have not explored that idea since. Hence, “handshake”.

I’d seen how you could simplify the reply, but I guess that without being able to strip out the OSC, er, message framing (?) the response may not be straightforward to interpret?

Possibly my first hurdle – in the absence of any proper understanding – is how to send a data packet on one port and listen for the reply on another with the tools that are already built in.

Rich

[Chris Ashworth]

On February 9, 2017 at 9:17:05 AM, Rich Walsh (rich...@mac.com) wrote:

I think when you first introduced OSC I came away with the impression that you had to /connect {passcode_string} before something outside of QLab could talk to it – rather than just send orders – and have not explored that idea since. Hence, “handshake”.

Ah, that’s true; you could get around this by always sending the passcode before every message you send, fwiw.

I’d seen how you could simplify the reply, but I guess that without being able to strip out the OSC, er, message framing (?) the response may not be straightforward to interpret?

I agree with that assessment.

(Long term, I am interested in filling in “dumber” plain-text protocols to allow avoiding all this OSC business.)

Perhaps using a dummy cue as storage isn’t the worst approach in this case?

-C

Possibly my first hurdle – in the absence of any proper understanding – is how to send a data packet on one port and listen for the reply on another with the tools that are already built in.

Rich

On 9 Feb 2017, at 13:49, Chris Ashworth <ch...@figure53.com> wrote:

I can at least answer the last question:

Depends on what you mean by handshake routine, but if you are using UDP QLab will still reply to external queries and since UDP is connectionless it just sends the reply to port 53001 on the IP address it got the request from.

Thus, if you have something that can parse the reply you can use it that way.

One additional feature that could help here is the new ability (in version 4) to specify a reply format.  By default, it looks like this:

http://figure53.com/docs/qlab/v4/scripting/osc-dictionary-v4/#reply-format

But the Application Methods :

http://figure53.com/docs/qlab/v4/scripting/osc-dictionary-v4/#application-methods

includes the command /replyFormat which you can use to set a custom format for your client.

You can use this to simplify the kid of reply you get back, so that if you don’t want to e.g. parse JSON you can set it up to just send back ONLY the data of the reply and no other information. (it’s still OSC though; there’s no text-only protocol at this time)

-C

I’ve hit a dead end in my understanding of OSC. Thanks to Mic’s work on animated eyeballs I can see how to use the response to an OSC “query” as a variable in another OSC command, but I can’t work out how to use a response in a more general way… 

For example, something like /cue/{cue_number}/maxTimeInCueSequence looks quite interesting and useful, but not if I can’t get the answer into AppleScript to work with. 

I know how to use nc to send commands to QLab, but I haven’t found a simple solution to listen for the reply yet. Is there one? Do I need to use something like Python to do this – which is a little bit beyond my knowledge at the moment? 

It’d be a shame to have to use a dummy cue and do things like "/cue/999/preWait # /cue/1/maxTimeInCueSequence #”, and then query cue 999. 

Has anyone written a neat little shell script that can send an arbitrary OSC command to QLab and parse the answer? Does QLab even reply to external queries without going through a whole handshake routine? 

Thanks. 

Rich

--
Contact support anytime: sup...@figure53.com
Follow Figure 53 on Twitter: http://twitter.com/Figure53
---
You received this message because you are subscribed to the Google Groups "QLab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qlab+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qlab/04AC9E4C-ED7A-4E96-BFB2-321987D6A3F3%40mac.com.
For more options, visit https://groups.google.com/d/optout.

[Rich Walsh]

Perhaps using a dummy cue as storage isn’t the worst approach in this case?

Are you suggesting I use the $999 tool I already own to send, receive and parse OSC?

Hmm, maybe QLab itself is the simplest answer.

(Again.)

Rich