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!