Structure of OSC commands sent to QLC+

[highkeymichael]

I have previously used QLC+ to do some visualization with robotic lighting in Capture 2020. Once I learned how to use it, setting up the scenes I wanted was pretty easy, and so now I’ve come back to it for my next project.

In my current project I want to use a Raspberry Pi to send OSC messages to QLC+ so that it can trigger scenes which will then be translated to a robotic light with an Enttec Design Spot 300 Pro. I’ve created a fixture definition successfully, but now that I want to control QLC+ with OSC, I’ve hit a bit of a snag:

I don’t know how to structure my OSC message and how to create a working OSC profile in the Inputs/Outputs window.

Since I’m controlling QLC+ with a Raspberry Pi, I’ve been using a very minimalistic command line utility based on node js to send OSC commands called oscurl (https://github.com/russellmcc/oscurl). I tested it earlier this year and got the utility to trigger QLab cues successfully.

I did that on a Mac and now for testing purposes I’m running the utility (which seems to require the use of a unix system) on Windows under WSL and sending the OSC commands through the loopback address to QLC+. I can confirm that the packets are arriving to QLC+, as the packets received counter increments each time I send a message.

I’ve sent messages like the following:

Code: Select all

oscurl 127.0.0.1:7700 /0/dmx/2 255
oscurl 127.0.0.1:7700 /0/dmx/2 0

to see if it messes with the simple desk sliders

Code: Select all

oscurl 127.0.0.1:7700 /hi/0 28

to see if it can auto detect the osc input

When I run

Code: Select all

oscurl 127.0.0.1:7700 /0/dmx/2 255

Wireshark displays that the following data is sent:

Code: Select all

/0/dmx/2,s255

Is the issue here that the type information (I assume that the “s” means string) means that QLC+ ignores the command because it isn’t receiving a numeric value?

Even when I send an empty string with

Code: Select all

oscurl 127.0.0.1:7700 /0/dmx/2 ""

it appends the type information:

Code: Select all

/0/dmx/2,s

What OSC commands do I need to send to QLC+ to get it to work? Will the string type information break all types of OSC commands, or only one that control sliders / things with numeric values? For instance, would a button ignore this type info?

Any help is appreciated.

Edit: I took some captures a couple days ago of the traffic generated by toggling buttons with Touch OSC's automat5 configuration in QLC+. The packets to toggle it on/off are structured as such (I'm not nsure which capture is on and which is off though). Note that the type information seems to be "f" for what I assume is floating point

Code: Select all

/toggleC_1,f?
/toggleC_1,f

[mcallegari]

If you have the chance, launch QLC+ with debug enabled (-d option)
You can't do that with a offical released version. Try test versions.

Second, yes, I think you need to send values 'i' or 'f' should do.

Third, I suggest you to create an input profile and see what QLC+ detects

[highkeymichael]

Thanks @mcallegari, I was able to figure out that the string type information is what mucked it all up. When I send an OSC command from QLab with floating point values, that can successfully trigger a button in QLC+.

I was considering suggesting supporting OSC commands that could flip-flop the state of buttons on the virtual console, that ignores type information provided. The rationale behind this suggestion is that the node js OSC library(osc-min) that powers the simplistic command line tool oscurl is a relatively popular one, as shown by a cursory search on GitHub: https://github.com/search?q=%22osc-min%22&type=code

It seems that the default behavior of this library when using the osc.toBuffer function is that when a type is not provided it defaults to using string type information, resulting in my frustration when not able to send an OSC command properly.

However this is probably a bad idea because upon further inspection what I thought were "toggle commands"(imaginary terminology for OSC commands without arguments that toggle the state of a button) sent by TouchOSC actually contained floating point values, I just was too blind to see that at first.

"?" is actually a byte that represents 1.0:

Code: Select all

/toggleC_1,f?

There's no question mark here because what was interpreted as the null character by wireshark was actually the floating point value for zero:

Code: Select all

/toggleC_1,f

Since there is no functionality in OSC to support "toggle commands" it would probably be unnecessary work that would resolve very few problems but introduce more complexity to the OSC system in QLC+.

There are two ways I could've resolved my problem, and I took the first:

• Use oscurl to trigger QLab cues(which seem to ignore type information as the go command doesn't require arguments) which send the actual commands with floating point values to QLC+

• Rewrite osccurl so that it specifies the type argument in osc.toBuffer as floating point and parse floating point numbers