Hi! Just wanted to follow up-
The patch you two (@whale-av & @ddw_music) helped me with is still working as designed!
I just deployed the second pi with the slightly modified patch for the second studio-
For those who could use it, here's the program with OSC commands EOS Element 2 lighting board, and X32 audio board by Behringer.

Could be wrong, but it sounds like wiringpi works with the pi5 now- can anyone confirm/contest?
When I looked into it about a year ago it seemed pretty far away... Thought it'd be cool to have pd on a pi5 for DIY hardware projects. No teensy/arduino/middleman to get sensor values.

Any luck getting the camera in Gem? Interested in this.

Thanks! it means a lot. To both @ddw_music and @whale-av ! In the past, while digging around the internet for info on puredata, I've come across posts from both of you that ended up being the best information I could find, so yeah, I've been pretty stoked for help from both of you. It's working! I'll setup another patch for another studio here.. It has a different lighting board, but I feel fine about setting up OSC for that. I'll write back with a report on the patch's resilience after some time has passed.

Success!
Here's the patch...
on-air-light-kmtr-v6-OSC.pd
Thank you both! I waited a long time to ask for help and.. All I can say is that I wish I did it much earlier!
Funny how people tend to wait..

I think I'm going to deploy it today and see how it goes. Hoping for as low-maintenance as possible.

Obviously- feedback/suggestions are welcome.

I guess... Where would a good place to put a pd patch for people to use? I know there's this site... I see github pages a lot.

@ddw_music Yes- that was needed. I was getting very sloppy and just trying things because I was tired. I agree- at the least I should just stick to 1 set of objects. I appreciate the explaining of address space and command space. Honestly that screenshot comparisons of the 2 message's bytes is now in my onenote haha. And I appreciate the clarification about data type specifications (i, f, s, b ) applying to the data-half of OSC messages. Okay! Going to slow down, move sequentially, and yeah. Thanks. Will post back here with results per usual.

@ddw_music Fair enough! I guess that makes sense because sendOSC (mrpeach library I think) doesn't need that. I appreciate all the specifics about the syntax specifics for OSC that's needed when dealing with these more, 'standard' objects in pd. @whale-av maybe mrpeach can come out of retirement? I did find the git page where some externals are but yeah I couldn't get them to work without pd-extended which doesn't seem to be supported on 32bit bullseye armhf. Or- just as likely- I made a mistake while trying to install it.

I'm going to approach this tomorrow hopefully a little more fresh.. I feel like there is enough information in this thread to solve the problem. Here's what I made really quick, will experiment and modify it tomorrow. I realized your patch i was referencing (@ddw_music) was for simulating the X32 (to test getting responses back). But- there's some overlapping elements. I wasn't sure if the [oscformat -f i] was right... I think the -f initiates the "formatting", and then the i is for integer in the message being fed in the objects inlet? Which.. for the message [set /cs/chan/select/47(, might make sense, because there's the 47? I'll try it when I'm in front of the light tomorrow. Not sure if I need the 'list' or 'route' objects because I'm just trying to send..anyway, going to leave before I ramble too much more than I already have. Thanks

Okay! I thought I was done... So I cleaned up the patch.
Since then, I realize my OSC commands to the lighting board aren't working

I opened up the version of the patch from 2023 that worked, and I realized that I was using the [sendOSC] object.
So mr peach I think? For some reason I can't get the sendOSC object to work on the pi... But I think I have other parts of Mrpeach external working like packOSC. The old version of the patch ran on windows, which isn't as hard (for me) to get the mr peach patch working.

Here's the current version of the patch-
on-air-light-kmtr-v5-OSC.pd

I was SO ready to set it all up but I might have to come back to this tomorrow.
I figure it's still possible to use [netsend -u -b] since we did it with the X32...
But yeah, it's not working from what I tried.

It's a colorsource AV 20 board.. There's an IP, then an OSC IP, a receive port, and a send port. The netmask is 255.255.0.0 which is weird.. But I don't want to change it because we use a streamdeck to send OSC commands to the board and they work. I did change it for a minute and didn't see anything different.

@ddw_music said:

Think of the OSC address space like a tree. 'ch' says it's a channel-related message. That branch of the tree splits off into a branch for each channel. Then each channel has properties or commands, of which one is 'mix' and below that, 'on' is one of many properties. [route] "peels off" each descriptor one by one and you can build the responses literally as a tree.

Word!

Looks as though you are using MrPeach [unpackOSC] so you can strip the paths (message headers) with [routeOSC]
So a [routeOSC /ch/01/mix/on <space> /ch/02/mix/on... etc.]
for 0/1 for each path.

And word!
Okay- Thank you both! Will report back with results today... Pd is awesome.

Totally going to give credit to you two when I post this patch after it's finished!

@whale-av, @ddw_music, Thank you both for your help! Just wanted to post this before I head out:

pd is printing like it should! I went and muted channels 3 & 4, and it reflected right!
Unfortunately, right now I don't know why I didn't get these results earlier. Maybe the [unpackOSC] object before [print]?

Now... I guess.. How can I get the 0 or 1 value into the patch?

I venture towards something like... unpack list? unpack pipelist?
Any chance either of you two know a direction/method off the top of your head(s)?
Much appreciation- Jack

Geez I'm having a heckuva time installing pd-extended on this pi. It's 32-bit bullseye, armhf architecture. I have the (pd-extended_0.43.4~extended1-1~raspbian_wheezy_armhf.deb) file from sourceforge, and installed, but there was a failure....
It's been about an 1.5 hours of this so I'm running out of steam. I might try installing pd-extended on a windows machine to test the theory. I found a post where you say to install "pd-extended_043.4~extended1-1.deb" @whale-av.

aaaND oh gosh.. okay, while writing this I was dinking around, found the mrpeach external in the help browser... couldn't find udpclient, but opened up [udpsndrcv help] and saw.. Idk if we worked with this already? Because the port was already 10023- anyway-

Okay, yes I think we're getting somewhere.
Thanks for the specifics on the [udpclient] external @whale-av, I'll give that a shot.

Your first post also has some things I could try @whale-av ..Sending as Blob. It seems as though the messages are definitely getting to the X32 from pd.

@ddw_music, Yes! With SC, the message from the X32 is making it to localhost on the Pi, and then making it to pd. Which....I think could work- at least it seems we've shown it's possible. Would just mean there's a 'middleman' (localhost), which, would be fine (I think).

Mr.Peach is how I got OSC messages to work for the first time (personally), but yeah I think I need the right version of Pd to not break it. I'll give the [udpclient] object a shot. And- good to know that [netreceive] isn't necessary/wouldn't work anyway, so I'm dropping that. Thank you both! Hopefully I'll get some time today to try what we talked about here.

@ddw_music, you said, "I'm still suspecting firewall here. You said it's working on the Pi -- if the Pi isn't running a firewall but your computer is, that could block incoming messages.". I'm VNC'd into the pi from my computer, so I don't think a firewall on my computer would make a difference, right? But I agree ports might be blocked... It's weird that they can make it to localhost though but not the pi's IP.

@ddw_music Okay, so I've installed super collider on the pi and I got the responses!
I got the "got it" message in super collider, and I also got the reply in pure data ("reply") from super collider ( I think that's what's happening).

So basically... This proves that pure data will print received OSC messages on the right outlet of [netsend -u -b]. Is that right? I'm kind of rushing through this.

Still have to try connecting via TCP @whale-av. Will return probably tomorrow.

@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!

@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 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...

@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.

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

@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.