OSC

[sophielouise]

Dear community,

I want to set OSC as an input and have a fader update its value according to the input as well as passing the DMX value onto the output of QLC+. Attached is the simplest setup with one dimmer for channel 1 assigned to a fader on the virtual console. The fader should be mapped to the OSC address of /0/dmx/1. I mapped the fader to the OSC "channel number" according to the QLC channel mapper which gave the value 45745. I was unsure whether the value should be an integer between 0-255 or a float between 0-1. So I tried both as input coming in and neither worked. I set OSC as an output and recorded the value for /0/dmx/1 and assured that the OSC binary message I receive from QLC for the address /0/dmx/1 is the same exact binary message I send to QLC for that address.
Still, I can manipulate the OSC data (using PureData) and the fader does not move at all. I have verified that QLC is receiving OSC data by viewing the "packets received" for OSC on the Inputs/Outputs manager. I then send data and click off of OSC and then click back on OSC to refresh the "packets received" value". "packets received" reads a higher number after.

So I am not sure what it is I am doing wrong. Have a discovered a bug?

OS: Ubuntu/Linux 16.04
PureData 0.48 (latest)

Thank you,
- Sophie

[mcallegari]

I'd say the first thing you could try is to enable the debug messages by launching qlcplus -d, which might give you an indication of what is going on in the OSC plugin.
Obviously you can do that on a debug build. Which OS are you using ?

Otherwise you could capture with Wireshark the packets sent by Puredata, and share the trace here so I can have a look at it and see if there's anything wrong.

[sophielouise]

I am using Ubuntu/Linux 16.04.
I did not know about the debug mode. Thank you!
I only got the following message when I set the input and slide the value up and down:

"virtual void OSCPlugin::setParameter(quint32, quint32, QLCIOPlugin::Capability, QString, QVariant) "UniverseChannels" is not a valid OSC parameter"

I did notice that next to "Universe 1" a joystick icon appeared when it received an OSC packet.

[mcallegari]

You can safely ignore the "UniverseChannels" message.
It's there for some specific usage cases (e.g. SPI universe span)

If you see the joystick I think it is a good sign.
Strange you don't see any other debug message. Are you using an OBS build ?
If so, the 'official' versions are not debuggable, while the -git versions are. You might try the latest and see more debug messages.

[sophielouise]

Thank you! I did not know about the OSB build and the difference. I downloaded QLC+ from http://www.qlcplus.org/downloads.html and used the Linux 64bit download. I am currently on 4.11.0.

So, I want to be clear on this before I go through all of the work...
I should clone the repository from https://github.com/mcallegari/qlcplus/wiki pulling down all of the source code and then compile the program on my computer with the instructions here https://github.com/mcallegari/qlcplus/wiki?
I assume I use Qt5 if I can, otherwise Qt4.
And, I get a debug version of the program by compiling with the default configuration?

Can I have the two different versions on my computer? Or am I going to need to create a package?
If I create a package, do I need to set a higher version number for it? What command would I use to roll back to the 4.11.0 version?
Although, it might be time I just install the 4.11.1 version after debugging.

I am a programmer but have mostly worked with scripting and not compiled languages.

Grazie,

[mcallegari]

Most likely you don't need to build anything.
OBS builds of the Qt5/GIT versions are here: https://software.opensuse.org/download. ... us-qt5-git

Try one of them and see if you see something.

And no, you can't have multiple installations of QLC+ at the same time on Linux.

[sophielouise]

Massimo,

I do not seem to be receiving any errors. The command line output when sending OSC looks like this:

Code: Select all

 [OSC] path extracted: "/0/dmx/1"
[OSC] Tags found: 1 currpos at 16
[OSC] iVal: 168
[OSC] message has path: "/0/dmx/1" values: 1
 [OSC] path extracted: "/0/dmx/1"
[OSC] Tags found: 1 currpos at 16
[OSC] iVal: 169
[OSC] message has path: "/0/dmx/1" values: 1

My fader is mapped to 45745 which is the number I got from the channel mapper in the inputs/outputs section for the OSC address "/0/dmx/1". Did I do something wrong here?

Also, could you clarify whether I should be sending 0-255 integers or 0-1 floats for the OSC values? Or will both work?

If you think I have found a bug, let me know and I will start to dive into the codebase.

[mcallegari]

Also, could you clarify whether I should be sending 0-255 integers or 0-1 floats for the OSC values? Or will both work?

They should both work. In fact, you see iVal: 168 which means an integer value has been correctly extracted.

Can you try to create a new input profile and enable channels autodetection ?
Then send data from Puredata and you should see the profile filling in. If the channel number QLC+ calculates is different from 45745, then it means the channel number calculator is not right, but I doubt that.

[sophielouise]

Thank you Massimo! We are in business.
Earlier, I had tried using the auto detect on the fader setting. But that was not working. So that must depend on a profile existing.

I created a new profile and used the auto detect wizard for the profile editor. The address came through, but it came in one number higher. The address was 45746. After saving that profile, I was able to use auto detect on the fader setting which selected the newly added address of that profile. With 45746 as the "channel" the fader properly responded to the incoming OSC signals.

======

Now for my final question for this thread...
Do you have any thoughts or opinions on a new feature to simply type the OSC address into a virtual console control (fader/knob/etc)? How difficult would that be to code into the system? Do you think a refactor would be involved? It would feel natural to me if OSC mapping worked that way. But the channel numbers seem like a design decision to circumvent problems. Or, the channel numbers tie in with existing behaviour for other types of input. I am asking so that you can guide me on whether I should explore the codebase to contribute this feature.

The desire for this feature comes from the fact that my OSC controller is translating from MIDI and going to have as many addresses that are unique to every combination of control for every note.
So... 16 MIDI channels X 128 MIDI programs X 18 MIDI controls X 128 MIDI notes = 4,718,592 OSC addresses. How I feel about having that potential: . How I feel about having to write that profile: .
I don't want to add that many addresses to a profile and there may even be a performance hit to doing so.
If I end up having to create that profile, I will consult the data format and try to programmatically write the file the first time.

Thank you for your support and your contributions to this program!