Hello,
I've been working on this for a couple years now... I'm very close!

Hardware: Raspberry pi 3B
OS: Bullseye, pd .51
Peripheral hardware:

• Behringer X32 audio board. Physical and network MIDI out, can do OSC over MIDI sysex (osc documentation link)
• Colorsource AV board, can be controled via OSC

Here's my patch

Goal: When any of channels 1-4 are unmuted on the X32 audio board, a DMX light turns on (has 'on-air' stencil and a red gel attached to the front). When all 4 channels are muted, the light turns off.

The problem: This works- the issue is that sometimes pd or the X32 will mess up and a MIDI message is missed, so one of the 4 mute toggles (in pd) will be the opposite of what the actual mute status is of that channel.

My idea to fix: "Ask" what the mute status is of each channel every 10 messages or so.

Overview: I found the MIDI that the Behringer X32 spits out when muting channels, then used 'sel' to start, bondo sums and when the total gets to 4, an OSC message is sent to the lighting board to turn on the ON-air light. When it dips below 4, a message is sent via OSC to turn the light off.

I can't seem to get return values from the X32. With the X32 livetoolkit software I know that sending [/ch/02/mix/on] will return [/ch/02/mix/on ,i 1]. The send command doesn't need a value type (float, int, etc.), but the return value contains an int, which is either 1 or 0, which represents the mute as on or off. I can't get any return values from the board. I'm trying UDP with netsend -u -b 10.136.124.112 10023.

Also- I'm getting MIDI to the pi with the... UM-ONE midi to USB dongle. I forget the manufacturer but I think it's pretty common with Pi's and Pd.

If someone has a better idea that to achieve what I'm trying, I'm good with that too!

Any help would be appreciated! It feels so close and this will be my first 'new' thing I've made.

@jbaker said:

I can't seem to get return values from the X32. With the X32 livetoolkit software I know that sending [/ch/02/mix/on] will return [/ch/02/mix/on ,i 1]. The send command doesn't need a value type (float, int, etc.), but the return value contains an int, which is either 1 or 0, which represents the mute as on or off. I can't get any return values from the board. I'm trying UDP with netsend -u -b 10.136.124.112 10023.

I think the receiving bit should look like this:

If I send back to the same port e.g. /hi/back 1 then, after list trim, the message looks like hi back 1.

[fudiformat] / [fudiparse] is a workaround to handle the numbers in the OSC path.

BTW those "send /xxx/yyy/zzz" -- pretty sure that's not standard OSC -- I crashed SuperCollider trying to send to it that way.

This is the right way to send a properly formatted OSC message. Leading zeroes can be escaped, e.g., set ch \02 mix on, bang would send /ch/02/mix/on.

hjh

ddw_music thanks for this info! I appreciate the clarification about formatting OSC in pd in general, this will help me for a while to come.
Thanks for the info on [fudiformat] / [fudiparse] and the info about "[set ch \02 mix on, bang] would send [/ch/02/mix/on]."

So... I'm trying this and not seeing any messages print. Is the 57120 a common udp return port for OSC devices? I assume that the X32 is sending messages back on 10023 (the port I'm sending to).

I uploaded the patch in the screenshot. Again- thank you for your reply

ON-air-light-forum1.pd

@jbaker said:

So... I'm trying this and not seeing any messages print.

You need a bang.

OSC's "normal" case is to send many messages with the same command path, with different argument data. So, oscformat sends only when receiving data values in the inlet.

To send a data-less OSC message, command path only, use a bang instead of data.

To make that more convenient, use Pd's messaging logic to bang automatically:

So any message you send into the [pd] subpatch will do "set" then "bang."

Is the 57120 a common udp return port for OSC devices?

Well, I don't have your device, so I wasn't testing on the same port.

Everything above is totally independent of the port number.

hjh

@jbaker It looks as though the X32 requires a type tag string in osc messages, where the the data atoms after the message header /this-that are defined as integer(32) float(32) string and blob.

The "livetoolkit software" is probably sending the type tag "behind the scenes".
You can list the first 3 types in any combination as required, or send all the data as a blob (maybe, I have always defined the data when this problem arises).
In Pd [oscformat] help has information on how to do that (see the [format( message to be applied), or you might be able to include the definitions in your message like this....... https://showcuesystems.com/scs11help/index.htm?context=1240
I am unsure whether that would work, as it might be a specific method for the software detailed in that post.... but the [format( message in Pd should do the job.

If you put a [print] after netreceive you will see returned messages and can confirm your port addresses, as obviously you need to actually be receiving data before it can work. Unfortunately the M32 just discards messages it does not understand.

So define your message header in [oscformat header]
Send in the message [format i(..... probably.
Send your data into [oscformat]
David.

@whale-av said:

@ddw_music It looks as though the X32 requires a type tag string in osc messages, where the the data atoms after the message header /this-that are defined as integer(32) float(32) string and blob.

@jbaker ^^ this -- it means that your guess about putting slashes between all the parts of the message wasn't a valid approach.

@whale-av indeed, I thought it was a bit odd to have these long command paths with data in them. It definitely makes more sense with typetagged arguments.

hjh

Thanks ddw_music! That information on datavalues triggering oscformat to send is useful. Thanks for showing a way to do it. I'm going to try this and will post back here with findings. Very good to know. And a subpatch would be a good idea... It kinda feels like there's too much going on in this one patch. I think my brain just works better when it's all in the same window. But growth is good! Again- thank you.

@whale-av From that link you posted (@av-whale) I read this...

"OSC messages are not sent simply as text strings - the messages are assembled in a very specific format for transmission, including converting the int32 and float32 arguments to 32-bit values (either integer or floating point), and ensuring all parts of the message are 4-byte-aligned,"

This makes sense, because when I was sending messages formatted as [send xyz 123 456] I was getting an error on the x32 screen saying something like, "Message not formatted as 4-bytes" or something along those lines. I was coming up short trying to find info on that error, but this answers that question.

Thank you both! I'm going to try this today (as long as I can find some time). Super exciting! Thanks for spelling it out at the end of your reply @av-whale.

One thing I was going to say- the formatting like, [send /cs/chan/at/0] does work for the lighting board (to turn the on-air DMX light on/off, those messages are highlighted below), but I'm not getting anything in return (and don't need to).

Also, I had a bang connected to [send ch mix 2 on] in the last patch, but yeah the formatting wasn't quite right.
Again, thank you both. I'm going to look at the oscformat help patch and will post here (with findings) when I add it into the patch. Hopefully today.

Think we're on to something here!

I'm still kinda trying to understand the formatting, going to play with this some more.
I suppose... Once I get.. Oh shoot I just realized it's probably just printing what I'm sending.. I think I should receive a "1" or "0" representing the mute status "on" or "off". I'll post again when I come back to this after lunch

@jbaker Yes, I imagine 1 or 0 is likely.
Try....
[set ch 1 mix on, 1(
[set ch 1 mix on, 0(

I don't know whether the X32 will return any osc message when a parameter changes though.
David.

@whale-av Okay... So I just realized that [the bracket and parenthesis represents a pd message(
Okay, I think I did what you suggested..

I don't think the X32 will return an OSC message when a parameter changes.. I know there's a 'subscribe' osc command, but I don't think I need it. Since the Mute toggles are controlled by MIDI CC messages that the X32 sends out whenever there's a mute/unmute, I was going to hookup the same bang that triggers the OSC message to turn on the light (when 3/4 channels are muted) to also bang the [set ch 01 mix on, 1( message. From there, I'm hoping to get a 1 or 0 back from the X32, and have that 1 or 0 (which is the OSC message received from the X32 representing a channel's mute status) in pd connected to the mute toggle.

So basically, 'ask' the X32 what the mute status is to double check the existing mute toggles. Not that anyone asked to me re-explain.
I just can't get anything From the X32 in pure data (from net receive). Still going to explore the things we talked about here when I get more time.

[EDIT] I forgot to attach the screenshot! And while editing this I noticed that I'm now getting more numbers at the end of the message in pd console.... The last number changing when (it looks like) the same command was sent. I think that long list of numbers in the console is the "blob"? It's beside the point. But I know the X32 will send data back and you sometimes have to 'pick' out the values your looking for from it. Do the highlights mean anything to you two (or others)? I should go in front of the mixer and test really. I'll send an update.

For testing purposes here, you have two [print reassembled] -- meaning that you have no idea which one is printing. If you give them different names, the console window output will be less confusing.

I'm pretty sure [netreceive -u -b] isn't doing anything because it hasn't opened a port.

[oscparse] does not give you /ch/01/mix/on -- it gives you ch 01 mix on -- which has to be peeled apart by multiple [route] objects. Then there's the fun thing about numbers in OSC command paths. So I'd suggest:

Because the device has numbers in the path, you have to use the [fudiformat] / [fudiparse] workaround. Don't worry if you don't understand why, just, do not delete them.

(The netsend right outlet thing is based on the assumption that the device is sending back to the same port that Pd sent from. This might not be true -- in that case, you'd need to find out how the device is sending and configure the patch accordingly. Also double check to be sure the firewall isn't blocking Pd from receiving.)

hjh

@jbaker It seems that maybe data can be requested from the X32 with an osc formatted message starting /formatsubscribe .... for specific parameters... and permanently? or just for a limited time...... and are future button presses on the console also (or only) returned...?
/web in the address.... can this be replaced with "IP:port"... ?

Complete and (so far) incomprehensible osc info here....... https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://tostibroeders.nl/wp-content/uploads/2020/02/X32-OSC.pdf&ved=2ahUKEwjq9e_w2JqMAxXCdqQEHXAeISkQFnoECB8QAQ&usg=AOvVaw2xQyrtSBeKrEBddafvVqiG

It would be great if you can find the return port number for osc on the X32.

It seems that on/off (enum) and 1/0 (integer) are interchangeable, but it is not clear (yet...!) whether they are part of the message header or data following the header.

 all parameters must be big‐endian and 4‐byte aligned/padded, as per OSC specification.
 padding is done with null bytes.
 float parameters must be in range 0.0 – 1.0, e.g.:
0.0 0x00000000 (big-endian)
0.5 0x3f000000 (big-endian)
1.0 0x3f800000 (big-endian)
 integer and float parameters are signed 32‐bit values.
 strings must be null‐terminated.
 enum parameters can be sent as strings or integers (see below).
 boolean parameters will map to enum type {OFF, ON} (or OSC integer {0, 1})
 blobs (arbitrary binary data) follow specific rules depending on the section they apply to (see later in this document)

Too much reading for me today...... maybe later...
David.

@whale-av said:

@ddw_music It seems that maybe data can be requested from the X32...

With apologies but why do you keep addressing these to me? It's not my device or my question.

I was trying to fill in some gaps for jbaker about how to use the Pd OSC objects. My interest ends there, tbh.

hjh

@ddw_music Sorry, I replied to the wrong post.... will try to pay more attention in the future.
David.

@ddw_music Okay, I made the changes but not getting anything back. It looks like pd likes the formatting...I'm not getting any errors. I'm guessing that the X32 isn't replying on the same port we're sending to (with pd), but that's also an assumption. Somehow the livetoolkit software can just display the whole reply. I've read through that OSC doc- it's linked in the original post. I'm not sure if wireshark would help? I'm guessing that if it is on a different port, the return port changes, which would be a hassle... But yeah, the livetoolkit software somehow works great.
In this screenshot, I added the [print packet] since nothing was printing. It looks like nothing from [print reassembled] is printing... The messages in the console are from clicking the messages at the top, sequentially.

In this screenshot, I toggled the mute (with the X32 software that controls the board) and sent the same message, getting a reply that indicates the change I made. So that works.... The send message has no 'value' type, but choosing 'string' works as well as 'no value'.

I had a thought last evening... What if I made a physical button connected to the Pi, that basically mutes channels 1-4 on the board, and also resets the 4 mute toggles in the software? Or even better, automatically did that once per day around 1am or something... I think it would achieve the same effect.

My old coworker was able to query the X32 for channels 1-4 fader values using a python script.. It might be worth looking at that again. It basically turns on a speaker in the studio whenever channels 1-4 are muted so the people in there can hear the 'program' audio, aka, hear what's playing when they aren't talking. I think it uses the /subscribe command but... Not sure. I'm just not much of a python guy, but some of the OSC commands/formatting might glean some information.

@whale-av, "It seems that on/off (enum) and 1/0 (integer) are interchangeable, but it is not clear (yet...!) whether they are part of the message header or data following the header.", yes... I think it's at the end? Not 100% on that. These parts from the OSC x32 doc might help... Whenever I try to send pd messages with tilda's I get errors though.

Thanks for the help .. I'll try to dig up that python script. It works with 2 X32's 24/7 on a single pi and only needs reboots a couple times a year. It would be cool to get this going with pd since I think it's possible...

@jbaker I am not sure that the return data is working with udp....... [netsend -u -b]
Maybe try a tcp connection..... [netsend -b]
David.

@jbaker said:

@ddw_music I'm guessing that the X32 isn't replying on the same port we're sending to (with pd), but that's also an assumption.

There are basically two possibilities here:

1. The X32 sends its replies to a port of your choosing. If that's the case, then there must be a configuration option for "port" somewhere on the X32.
2. If there isn't place to configure the port, then it would pretty much have to be sending back to the Pd sending port. (It would make no sense to send to some arbitrary port that you have no control over and that is different from the sending port.)

That Python script should tell you whether it's receiving OSC on the same port from which it's sending, or on a different port.

One other thing to check -- are you 100% certain that the Pd machine's firewall is not blocking high port numbers?

When you "connect" a [netsend], the port number specified in the "connect" message is the port to which messages are sent. The from port (Pd side) isn't specified in this message, and (AFAIK) it's chosen randomly. If you have a firewall that allows traffic on only a few specific ports, that could be a problem for randomly-chosen ports.

The X32 Live Toolbox is receiving, but maybe that's operating on a specific port that was previously opened in the firewall.

You might also try SuperCollider for a test. SC by default sends and receives on port 57120. So you could test "reply to same port" like this:

n = NetAddr("10.136.124.112", 10023);

OSCdef(\ch02, { |msg, time, addr|
    msg.debug("got it");
}, '/ch/02/mix/on');

n.sendMsg("/ch/02/mix/on");

... and if the X32 replied to the same port, you should see "got it: [ /ch/02/mix/on, 1_or_0 ]" in the console window.

Whenever I try to send pd messages with tilda's I get errors though.

Don't. [oscformat] handles that for you.

@whale-av

I am not sure that the return data is working with udp

It does, actually. addr.sendMsg at left tells SC to send back to the Pd port where the message came from, and it comes through [netsend]'s right outlet just fine.

hjh

@whale-av I've watched that thought pass by, but haven't pursued it (I don't remember why). It's worth a shot- I'll try this and report back.

When I send OSC commands to the lighting board in this patch, it works fine. What's interesting is that the lighting board has a configurable OSC* send* port and configurable OSC receive port (8004 & 8005 if I remember right). But after reading documentation again, it looks like the X32 board receives and sends OSC on udp- not that I won't try TCP. In the unofficial OSC doc I read this...

@ddw_music Thanks for your reply!
About the two possibilities:

• No configurable port for receiving or sending

• Yes- I agree! That wouldn't make sense for the X32 to reply on a random UDP port.

I think you're right about the python script... I've finally looked.
It looks like it's sending OSC to 10023, and...it kind of looks like it's receiving on port 1024..? I'll try a [netreceive 1024] object and see what happens.

@ddw_music: "One other thing to check -- are you 100% certain that the Pd machine's firewall is not blocking high port numbers?"

I'm not 100% certain. Yes, the LiveToolKit x32 software is running on the Pi and can read the OSC messages from the X32... But if Pd chooses randomly the receive port with [netsend]... Should I just use a [netreceive (port#)] object? But I see what you're saying about the firewall. I'll try SuperCollider (thank you, more tools are always nice) and see what happens... Thanks for including that screenshot of SC to get me started!

Tilda's: Fair enough! I got the idea in my head from the X32 OSC documentation.

Will reply here with what I find... Thank you both very much!

@jbaker older Pd vanilla is silent in the console but 0.55.2 clearly states that UDP [netreceive] cannot send return messages on the same port.
Further investigation required.

So, as there is more help in pd 0.52.2 what you need is the left part of this..... just the [netsend] on the left of the screenshot below........ it must be told to use the same port for send and receive...... so [connect port sameport(
........ netsend-receive-help-mod.pd ... see [pd send-back-in-UDP] at the bottom left.

The original help specifies separate ports...
So it is not certain that it will work.... the data might only bounce back, but might go through to the X32 at the same time...? But it could fail to connect to the X32 at all.

After more testing....... pretty sure that the X32 will receive the sent data and you will receive back on the same port...... but that the data you send from Pd will also be reflected by the port.

Note that the "send" prefix is no longer needed for a list.
David.