OSC Routing error

[RandomContribution]

Have been trying to get this to work, I feel I'm close, but there is a setting or config I dont have right. Would you maybe have some suggestions of things I could check?

If I press a button in my X32, the xremote-proxy log shows "no router handled it" (.93 is my X32, my QLC is .63)

DEBUG: InetSocketAddresses (excluding ports) are the same: source 10.0.0.93/10.0.0.93 (10.0.0.93) = dest 10.0.0.93/10.0.0.93 (10.0.0.93)
DEBUG: Received message RawOSCMessage [oscMessage address=/config/mute/2] from X32 endpoint.
DEBUG: Recieved message RawOSCMessage [oscMessage address=/config/mute/2] from X32 endpoint but no router handled it.

[Jurrie]

Hi, thanks for the detailed report!

The message "no router handled it" is logged when xremote-proxy receives an OSC message that it does not recognize. And because of that, it doesn't know if it should be forwarded to QLC+ or not.

The handling of incoming OSC messages is here.

In your screenshot you write "Pressing MUTE group buttons on my 32". That's where the 'error' is. Currently, xremote-proxy only forwards the OSC messages for user-assignable buttons and encoders. So these things. (They might appear different for different X32 models.) Not for other things like mute group buttons.

I do like the idea though for forwarding "mute group button pressed" OSC messages as well. That would give the ability to trigger things in QLC+ by using mute buttons. So maybe lowering the intensity of the light show by 50% when the band is on a break or something. I'm not sure on when I'll find time to implement this though 😀

[RandomContribution]

I super appreciate your time to look at my issue. I'd really like to get this to work, I think this would be really useful for productions!

I'm using an X32 Rack, using the X32 Edit to control. I'm using the X32 EDIT "Assignment" GUI interface, which I feel should work the exact same way for this test as the actual physical buttons on a console. I use these assignments for other shows, so I see no issues.

I'm running the mixer for this test in a complete factory default configuration.

I restarted the proxy service, and logs show its running:

If I press any of the user buttons or dials, I get the same error:

I noticed that the message I see in the logs that when I press the button, it didn't match the value in the OSC profile

[oscMessage address=/fxrtn/02/mix/on] from X32 endpoint.
DEBUG: Recieved message RawOSCMessage [oscMessage address=/fxrtn/02/mix/on] from X32 endpoint but no router handled it.

I put in /fxrtn/02/mix/on into the profile in QLC but didn't make any difference.

I feel I have your application very close to working, but I'm missing a step.

[Jurrie]

Hmm, the OSC command that xremote-proxy is expecting should be something like /-stat/userpar/[id]/value. According to the unofficial X32 OSC documentation this is:

This command is used by X32/M32 to return to the application program (client) the value of a button or encoder actioned by the user, when a MIDI note, ctrl or pgrm changes are selected for the user control element. It can also be used to set the state of an encoder or button.

Did you configure your user assignable buttons to send a MIDI note? Judging by the OSC command that is reported, you assigned something like "effect on/off" to the button? (And I think your screenshot shows that that is not the case, but I'm not sure.) It should be "send MIDI note".

The way I use it is I assign MIDI notes to the user assignable buttons and encoders. I don't use MIDI in my setup, but if there's nothing assigned to the buttons, no OSC command will be triggered.

I realize that this is not optimal. Your case (triggering QLC+ on effect on/off) is a very valid one. It's just not something I thought of 😀 The program currently does not support your use case, but I'm certainly not against the idea.

Can you get it to work when assigning "send MIDI note" to the buttons?

[RandomContribution]

With Midi I don't see any messaging in the log file.

Do you have an example of what the message the xremote-proxy is expecting to see?
Your QLC examples contain values that I can't replicate on an X32
Your examples have "/button/B10/value" or "/encoder/B3/value" but my actions are more specific like =/`action/selsession

16:34:23 Received message RawOSCMessage [oscMessage address=/-action/selsession] from X32 endpoint.
16:34:23 Recieved message RawOSCMessage [oscMessage address=/-action/selsession] from X32 endpoint but no router handled it.

I assume a valid message would show some sort of log entry?
These screen shots are my system currently. Do you have an X32 scene file that I could try?

[Jurrie]

I don't have my X32 available here, so I'm unable to provide a scene or logging for you. But for testing I often use the TouchOSC template. You can download TouchOSC for free. I have set up a working test with TouchOSC like this:

I run QLC+ on 192.168.130.1 and TouchOSC faking the X32 on 192.168.122.1.

I used QLC+ template project.qxw and configured the OSC plugin to be:

• Input 192.168.130.1 (universe 1)
  • Input port: 7700
  • Output address: 192.168.130.1
  • Output port: 9000
• Output 192.168.130.1 (universe 1)
  • Output address: 192.168.130.1
  • Output port: 9000

TouchOSC configured with a single OSC connection as:

• UDP
• Host: 192.168.1221
• Send port: 100025
• Receive port: 10024
• Zeroconf: Default

I start xremote-proxy using the following command line:

xremote-proxy --run-in-foreground --x32 192.168.122.1 --x32-listen 192.168.122.1:10025 --qlcplus 192.168.130.1 --trace

Because TouchOSC is not a real X32, I start xremote-proxy with an extra --x32-listen argument. This tells xremote-proxy that it should also listen on 192.168.122.1 port 10025 for X32 OSC messages. I configured TouchOSC to send the messages to that port. If you use a real X32, the --x32-listen argument is not needed of course, the --x32 argument suffices. So your start syntax looks OK to me.

When I click the top left button on Bank A in TouchOSC (button A5) I see it light up in QLC+. So QLC+ is receiving the button press. The other way around also works: I click a button in QLC+ and see it light up in TouchOSC.

Here is the log I get for me clicking button A5 in TouchOSC.

The application is starting.

09:01:26:4025 main INFO : xremote-proxy version 0.0.4 (17cb09ca3542aacbb94122dc7ef8ec5ee028f658)
09:01:26:4456 main DEBUG: Application starting.
09:01:26:4898 main INFO : X32 endpoint started listening on port 10025 (sending to 192.168.122.1:10023 and all clients that send us a message first)
09:01:26:4921 main INFO : QLC+ endpoint started listening on port 9000 (sending to 192.168.130.1:7700 and all clients that send us a message first)
09:01:26:4938 main INFO : Application started.

Next xremote-proxy sends 2 packets to the X32, asking it to send any updates (for example: button presses) as OSC packets to us. The X32 is not responding of course.

09:01:27:4837 pool-1-thread-1 TRACE: Sending to /192.168.122.1:10023
09:01:27:4844 pool-1-thread-1 DEBUG: Sent /xremote to 192.168.122.1.
09:01:35:4752 pool-1-thread-1 TRACE: Sending to /192.168.122.1:10023
09:01:35:4761 pool-1-thread-1 DEBUG: Sent /xremote to 192.168.122.1.

Next I press (and hold) the top left button on bank A in TouchOSC. This is button A5.

09:01:37:3634 Thread-0 DEBUG: InetSocketAddresses (excluding ports) are the same: source 192.168.122.1/192.168.122.1 (192.168.122.1) = dest 192.168.122.1/192.168.122.1 (192.168.122.1)
09:01:37:3655 Thread-0 DEBUG: Received message ButtonChangeX32OSCMessage [button=A5, pressed=true] from X32 endpoint.
09:01:37:3670 Thread-0 DEBUG: Sending message to QLC+ endpoint: ButtonChangeQLCPlusOSCMessage [button=A5, pressed=true]
09:01:37:3689 Thread-0 DEBUG: InetSocketAddresses (excluding ports) are NOT the same: source 192.168.122.1/192.168.122.1 (192.168.122.1) != dest 192.168.130.1/192.168.130.1 (192.168.130.1)
09:01:37:3694 Thread-0 TRACE: Sending to 192.168.130.1/192.168.130.1:7700
09:01:37:3698 Thread-0 DEBUG: Sending message to X32 endpoint: ButtonChangeX32OSCMessage [button=A5, pressed=true]
09:01:37:3706 Thread-0 DEBUG: InetSocketAddresses (excluding ports) are the same: source 192.168.122.1/192.168.122.1 (192.168.122.1) = dest 192.168.122.1/192.168.122.1 (192.168.122.1)
09:01:37:3792 Thread-1 DEBUG: InetSocketAddresses (excluding ports) are the same: source 192.168.130.1/192.168.130.1 (192.168.130.1) = dest 192.168.130.1/192.168.130.1 (192.168.130.1)
09:01:37:3798 Thread-1 DEBUG: Received message ButtonChangeQLCPlusOSCMessage [button=A5, pressed=true] from QLC+ endpoint.
09:01:37:3802 Thread-1 DEBUG: Sending message to X32 endpoint: ButtonChangeX32OSCMessage [button=A5, pressed=true]
09:01:37:3804 Thread-1 DEBUG: InetSocketAddresses (excluding ports) are NOT the same: source 192.168.130.1/192.168.130.1 (192.168.130.1) != dest 192.168.122.1/192.168.122.1 (192.168.122.1)
09:01:37:3806 Thread-1 TRACE: Sending to 192.168.122.1/192.168.122.1:10023
09:01:37:3810 Thread-1 DEBUG: Sending message to QLC+ endpoint: ButtonChangeQLCPlusOSCMessage [button=A5, pressed=true]
09:01:37:3812 Thread-1 DEBUG: InetSocketAddresses (excluding ports) are the same: source 192.168.130.1/192.168.130.1 (192.168.130.1) = dest 192.168.130.1/192.168.130.1 (192.168.130.1)

I keep the button hold down and wait. Next xremote-proxy send 2 packets to the X32 again.

09:01:43:4752 pool-1-thread-1 TRACE: Sending to 192.168.122.1/192.168.122.1:10023
09:01:43:4760 pool-1-thread-1 DEBUG: Sent /xremote to 192.168.122.1.
09:01:51:4750 pool-1-thread-1 TRACE: Sending to 192.168.122.1/192.168.122.1:10023
09:01:51:4757 pool-1-thread-1 DEBUG: Sent /xremote to 192.168.122.1.

Next I release buton A5.

09:01:52:5249 Thread-0 DEBUG: InetSocketAddresses (excluding ports) are the same: source 192.168.122.1/192.168.122.1 (192.168.122.1) = dest 192.168.122.1/192.168.122.1 (192.168.122.1)
09:01:52:5259 Thread-0 DEBUG: Received message ButtonChangeX32OSCMessage [button=A5, pressed=false] from X32 endpoint.
09:01:52:5263 Thread-0 DEBUG: Sending message to QLC+ endpoint: ButtonChangeQLCPlusOSCMessage [button=A5, pressed=false]
09:01:52:5268 Thread-0 DEBUG: InetSocketAddresses (excluding ports) are NOT the same: source 192.168.122.1/192.168.122.1 (192.168.122.1) != dest 192.168.130.1/192.168.130.1 (192.168.130.1)
09:01:52:5277 Thread-0 TRACE: Sending to 192.168.130.1/192.168.130.1:7700
09:01:52:5283 Thread-0 DEBUG: Sending message to X32 endpoint: ButtonChangeX32OSCMessage [button=A5, pressed=false]
09:01:52:5287 Thread-0 DEBUG: InetSocketAddresses (excluding ports) are the same: source 192.168.122.1/192.168.122.1 (192.168.122.1) = dest 192.168.122.1/192.168.122.1 (192.168.122.1)
09:01:52:5382 Thread-1 DEBUG: InetSocketAddresses (excluding ports) are the same: source 192.168.130.1/192.168.130.1 (192.168.130.1) = dest 192.168.130.1/192.168.130.1 (192.168.130.1)
09:01:52:5392 Thread-1 DEBUG: Received message ButtonChangeQLCPlusOSCMessage [button=A5, pressed=false] from QLC+ endpoint.
09:01:52:5398 Thread-1 DEBUG: Sending message to X32 endpoint: ButtonChangeX32OSCMessage [button=A5, pressed=false]
09:01:52:5405 Thread-1 DEBUG: InetSocketAddresses (excluding ports) are NOT the same: source 192.168.130.1/192.168.130.1 (192.168.130.1) != dest 192.168.122.1/192.168.122.1 (192.168.122.1)
09:01:52:5415 Thread-1 TRACE: Sending to 192.168.122.1/192.168.122.1:10023
09:01:52:5421 Thread-1 DEBUG: Sending message to QLC+ endpoint: ButtonChangeQLCPlusOSCMessage [button=A5, pressed=false]
09:01:52:5425 Thread-1 DEBUG: InetSocketAddresses (excluding ports) are the same: source 192.168.130.1/192.168.130.1 (192.168.130.1) = dest 192.168.130.1/192.168.130.1 (192.168.130.1)

Now, the part where I press and hold button A5 might need extra explaining. Here it is explained per line:

09:01:37:3634 Thread-0 DEBUG: InetSocketAddresses (excluding ports) are the same: source 192.168.122.1/192.168.122.1 (192.168.122.1) = dest 192.168.122.1/192.168.122.1 (192.168.122.1)
09:01:37:3655 Thread-0 DEBUG: Received message ButtonChangeX32OSCMessage [button=A5, pressed=true] from X32 endpoint.

This tells us that whe have received a message "button A5 pressed" from the X32. (TouchOSC actually, but xremote-proxy thinks it's an X32.) This message must be forwarded to all QLC+ instances we know, and all (other) X32 instances we know. In general there is just one X32 and one QLC+, so the effect will be "forward to QLC+".

09:01:37:3670 Thread-0 DEBUG: Sending message to QLC+ endpoint: ButtonChangeQLCPlusOSCMessage [button=A5, pressed=true]
09:01:37:3689 Thread-0 DEBUG: InetSocketAddresses (excluding ports) are NOT the same: source 192.168.122.1/192.168.122.1 (192.168.122.1) != dest 192.168.130.1/192.168.130.1 (192.168.130.1)
09:01:37:3694 Thread-0 TRACE: Sending to 192.168.130.1/192.168.130.1:7700

This tells us that we forwarded the X32 OSC message "button A5 pressed" to QLC+ on 192.168.130.1:7700. Note that QLC+ will trigger an OSC response. We will see that below.

09:01:37:3698 Thread-0 DEBUG: Sending message to X32 endpoint: ButtonChangeX32OSCMessage [button=A5, pressed=true]
09:01:37:3706 Thread-0 DEBUG: InetSocketAddresses (excluding ports) are the same: source 192.168.122.1/192.168.122.1 (192.168.122.1) = dest 192.168.122.1/192.168.122.1 (192.168.122.1)

This tells us that we did not forward the X32 OSC message "button A5 pressed" back to the X32 again. Because the source and dest IP are the same, and because of UDP we must assume that this is the same client. If we would echo back to the same client, we risk a loop where OSC packets keep being sent back and forth.

09:01:37:3792 Thread-1 DEBUG: InetSocketAddresses (excluding ports) are the same: source 192.168.130.1/192.168.130.1 (192.168.130.1) = dest 192.168.130.1/192.168.130.1 (192.168.130.1)
09:01:37:3798 Thread-1 DEBUG: Received message ButtonChangeQLCPlusOSCMessage [button=A5, pressed=true] from QLC+ endpoint.

This is the response from QLC+. For every OSC message you send it, it will reply back with an QLC+ OSC message with the same information. In this case: "button A5 pressed".

09:01:37:3802 Thread-1 DEBUG: Sending message to X32 endpoint: ButtonChangeX32OSCMessage [button=A5, pressed=true]
09:01:37:3804 Thread-1 DEBUG: InetSocketAddresses (excluding ports) are NOT the same: source 192.168.130.1/192.168.130.1 (192.168.130.1) != dest 192.168.122.1/192.168.122.1 (192.168.122.1)
09:01:37:3806 Thread-1 TRACE: Sending to 192.168.122.1/192.168.122.1:10023

This tells us that we forwarded the QLC+ OSC message "button A5 pressed" to X32 on 192.168.122.1:10023. Note that the X32 will not trigger an OSC response.

09:01:37:3810 Thread-1 DEBUG: Sending message to QLC+ endpoint: ButtonChangeQLCPlusOSCMessage [button=A5, pressed=true]
09:01:37:3812 Thread-1 DEBUG: InetSocketAddresses (excluding ports) are the same: source 192.168.130.1/192.168.130.1 (192.168.130.1) = dest 192.168.130.1/192.168.130.1 (192.168.130.1)

This tells us that we did not forward the QLC+ OSC message "button A5 pressed" back to QLC+ again.

I hope this helps you in debugging your issue. I think the issue is in the X32 part, so maybe I would start with using TouchOSC instead of the X32 first. If you get that working, you could try the X32 again.

[Jurrie]

Based on your input I have released a new version of xremote-proxy. Version 0.0.5 improves the logging a little. (Notably: not logging that source+destination are the same when receiving an OSC message, and logging the OSC message's content in TRACE mode.) It also adds support for mutegroups (like you used in your initial bug report). You will need to import the new QLC+ profile for this. I have tested and verified mutegroups work by using Mixing Station, X32 emulator, xremote-proxy and QLC+. So no fussing around with TouchOSC. I hope this makes your debugging-quest a bit easier 😀