Querying External Devices

[drew...@omegaproductions.org]

All,

I am looking for a way to query an external device with OSC, and use its reply (or part of it anyway) as part of an AppleScript.  Basically I am trying to determine the live state of a device, and record that for future recall via an OSC cue.  The device will respond to the OSC query, but I have to figure out how to get that data into QLab.  Anybody have some experience with this?

Thanks,
Drew

[Steven Sokulski]

Text cues can be treated as persistent variables. But you're looking at using Apple script to query the device and change the value of the text cue to store that result for later usage, I think.

What's the OSC interface for the device you're looking to query?

[micpool]

Hi Drew

A work around, probably involving osculator may be the simplest way of achieving this. When we use OSC in AppleScript in QLab, we are generally only sending plain text that looks like OSC to port 53535.

I don’t think I have ever seen an example of AppleScript parsing incoming OSC packets.

If you can post the OSC you are sending and what the device is replying and the port numbers then I might be able to suggest a solution.


Mic

[drew...@omegaproductions.org]

I am interfacing with a d&b DS100.  I want to query the status of any parameter in the matrix.  The "read" OSC is the same as the "write" OSC path minus the value of the parameter.  Sending "/dbaudio1/MatrixNode/Enable/21/31" will get a reply of "/dbaudio1/MatrixNode/Enable/21/31 1" for "ON."  The DS100 receives on port 50010 and replies on port 50011.  I want to extract the value returned and record that for future use.  Or simply record the whole return string, as it is itself the message I would want to send later anyway.

This also opens up another line of questioning: are there OSC handles for the new DS100 network cue type?  I can make this work with custom OSC strings, but it's not as slick when going back to see what the cue does.

Drew

[Chris Ashworth]

Drew, 

I’m afraid I have no help to offer but I just wanted to note that this is a fascinating topic to me. I’m interested by how often problems like this come up when using QLab in advanced ways.  

There’s this collection of related ideas with variable storage, basic processing of data, and hooking together either different pieces of QLab or QLab with other programs.  

Interesting to ponder….

As regards our specific integration with the DS100 I’ll add your thoughts to our issue tracker, to consider in future updates to DS100 integration.

-C

[micpool]

The problem with the Osculator solution, which would work by taking the incoming values of the arguments of the OSC replies and appending them to a message that set a field in a QLab cue to that value, is that you would need a translation set up for every parameter of every address.(and the crosspoint reference numbers are part of the address not the arguments, so the enable status of a 10x10 matrix would require 100 translations to be set up.)

So Osculator is not easily going to provide a universal solution for every parameter of a ds100 using this method.

But, I assume you are going to have to program a network cue for every query anyway so the number of Osculator forwards is not going to be any more than the number of cues you are going to write, so perhaps it is an option? How many parameters are you actually going to query in your actual usage.

Mic

[Rich Walsh]

At the start of the thread I was wondering if there was a way of using OSC triggering to have incoming messages act on cues that could then be queried, eg: have an OSC message trigger an Arm Cue that arms a dummy cue. However, as the OSC triggering is limited to workspace-level events – not individual cues, as per MIDI – that wasn’t going to work.

Now knowing more about the context I wonder if it’s possible to change the workflow so QLab already knows the status of the DS100 because QLab itself set it? What’s the setup whereby something else is changing settings on the DS100 and then QLab has to ask? Can the system that is changing the DS100 tell QLab what it’s doing directly, or be eliminated?

What is meant by “OSC handles”? In 4.2.3 if I create a Network Cue to a DS100 patch I see something very similar to the QLab message interface. If I select a set of popups for “Matrix Input” “gain” “1” “0” the q name is "/dbaudio1/matrixinput/gain/1 0.0”. This is just like "/cue/1/start” for a QLab message. How much clearer could it be what a Network Cue does than this default cue naming system?

With OSC being so, er, open it’s hard to see how you could extrapolate a universal receiver to parse an arbitrary number of variables out of a reply – eg: a matrix node has 2 co-ordinates and a value, while coordinatemapping//source_position has 2 co-ordinates and 3 values…

I suppose if you could listen on a port and dump the translated OSC messages into a log as raw text you could construct the precise parsing form you need in AppleScript. Hmm, I wonder if there’s a way of reading the OSC input log file on the fly? Can Osculator do something like this: pass the raw text over to QLab?

Thinking out loud – not trying to be rude.

Rich

[micpool]

On Tuesday, April 24, 2018 at 7:13:21 PM UTC+1, Rich Walsh wrote:

I suppose if you could listen on a port and dump the translated OSC messages into a log as raw text you could construct the precise parsing form you need in AppleScript. Hmm, I wonder if there’s a way of reading the OSC input log file on the fly? Can Osculator do something like this: pass the raw text over to QLab?

No but what it can do is forward messages on a per address basis to port 53000 and Qlab will show them in the OSC log in it's status window, although they don't match any of QLab's addresses and so are ignored.

But that's a fairly pointless operation because you can with a couple more keystrokes use Osculator to  rewrite the address  so the values end up in a parameter field in the Qlab Network Cue that sent the request in the first place.

Again I am confused about the other device which is setting the parameters of the DS100 which QLab then needs to be able to read itself , in order to  set the parameters of the DS100 later, as described in  in Drew's post where he states  "Or simply record the whole return string, as it is itself the message I would want to send later anyway." 

Mic

[drew...@omegaproductions.org]

The idea would be to use a much more user friendly interface for live positioning of sound objects (in this case also known as 'actors') - namely the R1 remote software.  In R1 I can freely position objects on a touch screen, but at some point I want to record all those objects' positions for later recall in QLab (triggered by a scene on the console).  Much like mixing a song in a musical - I'm going to push all the faders around until I like it, then store the scene for later.  As opposed to storing each fader level individually, which is essentially what one has to do via QLab.

By "OSC handles" for a DS100 network cue, I meant to say AppleScript handles - typing while distracted.  I want to create/edit DS100 cues/attributes as part of the script.

The script wouldn't have to handle an arbitrary number of variables since it knows what question it is asking.  If I query the position of Object 1, I expect to receive two values in return separated by a comma.  I can even ask it for each coordinate value individually if needed.  The trick is just getting that data returned into the AppleScript.

I think this boils down to: "Can I use netcat to return an incoming OSC command as a string to an AppleScript?"  

Does that clarify anything?

Drew

[Wayde Buttimore]

I might have an idea, Busy out and About right now. But I'll jump in tomorrow :) remind me if I forget

Thanks
Wayde

[micpool]

Yes, that makes it a lot clearer and more manageable.

Step 1 send the get command for the parameters you want  to DS100 from QLab

Step2 DS100 replies to OSCULATOR which takes the arguments in that reply and changes the address  and reroutes so the values of the arguments end up in the geometry parameters of a  dummy text cue in QLab representing 1 actor (x y level etc)

Step 3 An Applescript  creates a group containing new network OSC  cues and creates the messages based on the values in your actor dummy text cues to create a 'Fire all' group cue that essentially acts as a scene preset. (IWouldn't it have been so much easier if the DS100 actually had a scene memory system internally)

This is all a bit clunky, but I see no reason why it wouldn't work. And it wouldn't take more than a day or so to come up with a usable system for say 40 actors.

I can't think of a way for Applescript just to receive the entire OSC reply message from DS100, store it as text (you would still probably have to use dummyQLab  cues to do this using the notes field) and then repackage that text as valid OSC packets that can be sent to an external device (as opposed to the netcat stuff you can send as plain text to port 53535). 

Hope that helps a bit

Mic

[Rich Walsh]

So for AppleScript handles you mean DS100 equivalents of:

q_num (text) : The QLab cue number, for QLab type messages.

q_command (number) : The QLab OSC command, for QLab type messages.

q_params (text) : The QLab command parameters, for QLab type messages. Not all messages have parameters.

To be honest these aren’t terribly useful because you need lookup tables like this:

set translation103_q_command to {1, "start", 2, "stop", 3, "hardStop", 4, "pause", 5, "resume", 6, "togglePause", 7, "load", 8, "preview", 9, "reset", ¬

10, "panic", 11, "number", 12, "name", 13, "notes", 14, "cueTargetNumber", 15, "preWait", 16, "duration", 17, "postWait", 18, "continueMode", ¬

19, "flagged", 20, "armed", 21, "colorName"}

Unless you can learn that you need to set q_command to 18 when you want continueMode…

I might have missed something, but at the moment it looks like scripting of DS100 cues is pretty much broken? You can’t get their properties or osc message type, and you certainly can’t get or set what they do. I think you have to use a standard address patch and write the OSC by hand to script it, at which point it’s easier than using the numbers for q_command as there’s no translation.

The point about an arbitrary number of variables wasn’t meant for your specific case, it was in response to Chris’s "variable storage, basic processing of data, and hooking together either different pieces of QLab or QLab with other programs”. I should look at what Osculator does. What I was trying to get at is that some variables needs to be parsed from the OSC Address Pattern as well as the OSC Arguments, eg: if you wanted to query your crosspoint delays you need to extract 3 values from "/dbaudio1/matrixnode/delay/1/2 0.3”. However, given that in the specific case of the DS100 you’ll only get a reply if you ask "/dbaudio1/matrixnode/delay/1/2” I see how you will already know 2 of those values. In a general case though – say, QLab in /alwaysReply mode – you’d need to be parsing any old OSC that comes your way.

I have had no joy finding a way of scripting receiving a UDP packet. I can open a port and listen with nc but not get anything into AppleScript. If you knew what you’re doing in Terminal you could probably capture a single packet and write it to some accessible output, but my bash Cookbook still remains unopened from an optimistic flurry of interest 9 years ago…

The important thing about netcat is that it doesn’t send properly encapsulated OSC: it sends UDP text that QLab has been taught to treat as if it were OSC. I don’t know how you’d go about scripting sending an actual OSC message – it’d be easier to use a Network Cue.

Rich

[Chris Ashworth]

Hi Drew,

This is likely a terribly stupid question on my part, but just to make sure we’re not missing something basic, you have seen that QLab can graphically position DS100 objects on a map of the scene as well?

Since you almost certainly have seen this, my natural follow-up question is to learn more about what would make the QLab side of this more useful to you.

Not that recording data from outside may not also be helpful, but at some level this sounds like the underlying problem is not about recording data per se but about improvements to how QLab allows you to manipulate the DS100.

Cheers,

Chris

[drew...@omegaproductions.org]

I am definitely aware of the graphical positioning in QLab and the ability to underlay a representation of the stage (which is fantastic!).  The problem with using Qlab for live manipulation of signals is that I can only interact with one cue/object at a time.  In R1 I can see all the objects at once, and manipulate them at will without having to think about which network cue, within which group cue, represents the current state of the object in question.  This is in the context of mixing live inputs, not playback.  During a tech rehearsal where blocking and cueing are changing, I want to be able to respond as quickly as possible, and then with a hotkey store the scene once it is set (or add a new one if need be).

I could have R1 and QLab on adjacent monitors so that R1 provides the overview, but that still necessitates cross referencing cues with objects before I can implement a change.

Drew

[Chris Ashworth]

Ah, that makes perfect sense, thanks for the additional discussion and explanation!

-C

[micpool]

So, is what you ultimately want something like a DS100 version of the QLab lighting dashboard with all the actors visible at once, on a representation of the stage, which can write a specific DS100 cue which would be capable of recording all the OSC messages representing the coordinates of all the actors as an array and playing them back to effect a scene recall?

In the meantime I’ll knock out a 2 actor version of my Osculator solution sometime tomorrow as proof of concept.

Mic

[drew...@omegaproductions.org]

That sounds like it would be ideal!

Thanks for digging into this with me.

Drew

[Wayde Buttimore]

Ok, I got something, may not be what you need but might be a good starting point.

Basically using a small nodeJS app, when a osc message comes in from port 50011, it then creates a new network cue in qlab, then updates that new network cue to the reply you got from port 50011.

Eg. DS100 sends reply "/dbaudio1/MatrixNode/Enable/21/31 1" the network cue created in qlab will now send "/dbaudio1/MatrixNode/Enable/21/31 1" to your DS100 (or whatever destination is selected)

It is very basic, so if the DS100 is sending lots of OSC messages you are going to get lots of new cues, so adding a IF statement to the javascript to only listen to replies from osc address "x" might help, but gives you a idea of concept...

Install:

download and install nodeJS on qlab mac - https://nodejs.org/en/

unzip files to desktop or somewhere (https://drive.google.com/open?id=1KsUJKqQPIdr9IaZAE1tf0vrQbZ3Ll7Ty)

open terminal and point to folder where files are (eg "cd /desktop/DS100") 

then start the app in terminal by typing "node app.js" then hit enter (to quit use CTRL + C)

and away you go! 

Send OSC message to DS100 from Qlab and a new network cue with the reply should be created. In theory 

Once again, very simple and will need more "logic" added to script to work how you want it to.

Let me know if its in the direction you are after.

Side note: Chris, looking at API, no way to create new cue via OSC and include all the data you want? currently i  have to send another OSC message to add eg. the OSC string message?

[Chris Ashworth]

Hi Wadye,

That’s correct; there is not currently a way to use a single OSC message to create a new cue with parameters other than the default cue templates.

-C

[micpool]

This seems to work quite well. 

As I don't have a DS100 lying around in my kitchen I have simulated the replies on port 50011 using QLab 2D fade Network Cues

These are sent to OSCULATOR which tells QLab to store the coordinates returned into dummy text cues 1 for each actor

This script then automatically generates a group cue with the OSC messages to replicate the current state of the actors coordinates in the  DS100

set actorcount to 2

tell application id "com.figure53.QLab.4" to tell front workspace

repeat with i from 1 to actorcount

make type "Network"

set newCue to last item of (selected as list)

set patch of newCue to 2

set osc message type of newCue to custom

set custom message of newCue to "/dbaudio1/coordinatemapping/source_position_xy/1/" & (i as string) & " " & translation x of cue ("Actor" & (i as string)) & " " & translation y of cue ("Actor" & (i as string))

set the q number of newCue to "temp" & (i as string)

end repeat

make type "Group" -- Cue numbers not altered from QLab defaults

set groupCue to last item of (selected as list)

set mode of groupCue to fire_all

set q name of groupCue to "DS100 Scene "

set tempcues to every cue whose q number contains ("temp" as list)

repeat with eachCue in tempcues

move cue id (uniqueID of eachCue) of parent of eachCue to end of groupCue

set q number of eachCue to ""

end repeat

end tell

You can then number and title it and move it to where you want (Cue will be created after currently selected cue so you can create it in place)

You can move all the mechanics to a separate cue list in a real workspace

You could easily put a script into the workspace to open the OSCULATOR patch etc.

QLab Workspace,  Osculator patch, and demo video attached.

You can use other fields in the actor geometry tab to store other DS100 parameters, and the system is quickly expandable to any number of actors with a bit of cut and paste.

Mic

[drew...@omegaproductions.org]

Mic,

This looks like just the thing!  Thanks.

Drew