@jbaker said:

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.

Python docs say that the number given to recv is the size of the receive buffer, not the port.

The snippet from the X32 docs that you posted is unambiguous: replies are sent back to the requester's IP and port. So the netsend right-outlet approach should be correct.

Everybody gets their head tied in knots over send/receive ports.

When you connect a netsend, this is giving the IP and port TO which messages will be sent: TO port 10023. The message packet itself contains the sender's IP and port. In Pd, the FROM port is chosen randomly and AFAIK there is no way to know it -- so there's no way to open a netreceive on Pd's sending port. So let's say Pd chose port 45227. You send a message to the X32 and the packet includes your computer's IP and port 45227. The X32 (per documentation that you showed) should send its reply to the computer's IP and port 45227, where it would come out the netsend's right outlet.

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.

"Suspecting" may be too strong -- at least, it's necessary to rule that out. (One not-so-ideal thing about Pd's use of random port numbers is that, in this case, you'd have to open a wide range of ports, or disable the firewall. If you could specify Pd's sending port, then you could open only that port in the firewall... but you don't know which one to open, so you'd have to open thousands of them.)

@whale-av

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(

That doesn't sound quite right to me. Pd here should send to 10023, but it will be sending from a port of its choosing, which isn't 10023. The X32 is sending back to the originating port (not to its own receiving port). So I think "connect aaa.bb.cc.ddd 10023 10023" would not work. The replies from the X32 will not be going to port 10023 on the computer.

hjh

@jbaker Pretty sure tcp will not work as the X32 states specifically udp.
My last idea will probably not work.. ?
You posted the X32 spec and it states that it is acting as a server.
Moving away from pure Vanilla..... the MrPeach and IEMnet libraries were extremely competent with especially osc messaging over udp.
The [udpclient] external should be exactly what you require..... udpclient-help.pd
From the iemnet library, some of the objects in the help file might be from the MrPeach library.

If you are trying to build your project entirely within Pd that might be the only solution.
David.

Btw from jbaker's screenshots:

• Pd is definitely receiving a message from SC sent back to the Pd port, on the local machine (so, netsend isn't the problem).
• SC is receiving a reply back from the X32, confirming that the X32 is sending back to the originating port.
• But Pd netsend seems not to be receiving on the same port from the X32.

One difference is that the Pd vs SC test was on localhost, hence nothing to block traffic. (Why wasn't the X32 reply blocked for SC? SC doesn't randomize its outgoing port.)

I still think something in the OS is blocking the messages from the X32, but only for Pd.

hjh

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.

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-

@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

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

@jbaker said:

pd is printing like it should!

... wha...? I don't see what's different but... glad it's working!

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

Pretty much like this -- the [pd ch1] etc. boxes just do

[inlet]
|
[route mix]
|
[route on]
|
[outlet]

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.

pd-osc-routing.pd

hjh

PS I didn't use MrPeach in this example bc I'm too lazy to install it.

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

It's a shame that the MrPeach objects from 2013 are still easier/better? than newer vanilla objects for OSC messaging.
They deal with string/float/symbol types without a user needing to know the formatting of the original.
David.

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

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.

@jbaker said:

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

There's no oscformat or packOSC before the lower netsend here, so, in that version of the patch, you aren't sending OSC-formatted messages to the lighting board. If the lighting board expects OSC, it won't respond to plain streams of ascii bytes.

hjh

@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

@jbaker

I'd like to make a suggestion: Pick one set of objects to handle OSC, and just use those. It's in the nature of a tech forum for different people to have different opinions and offer multiple suggestions, but mixing and matching many different approaches can also lead to confusion.

So, for example, your screenshot -- at the top left, you have [packOSCstream] (why this and not [packOSC]? ** ) and then below, [oscformat]. That's a source of confusion. These two objects have quite different ways of handling OSC addresses (or what I've been calling "command paths") -- two idioms. Nah, this is a good way to introduce mistakes. So, pick one that you're more comfortable with.

** Ah, I see, [packOSC} help says "[packOSCstream] is a way to send OSC over TCP or serial connections" -- but you're using UDP, so, not relevant. Again, simplify: [packOSC] or [oscformat], pick one and stick with it.

Also -- you've got elements of this patch where it's already been explained why they are incorrect. If you connect a "send..." message box directly to a [netsend -u -b], it will not send an OSC-formatted message. Since you are sending to devices that expect OSC-formatted messages, for OSC it is always incorrect to pass a "send..." message directly to [netsend]. Never do this. But, in the top left part of your patch, I count 3 "send" message boxes that are patched directly to [netsend]. Delete those patch cables.

(Similarly, at the bottom of your patch, the line of objects coming directly down from [list trim] --> [route ch] --> [route 1 2 3 4] -- this is a part of my example patch that I had labeled with a comment saying "this will not work." Copying and pasting the non-working part is again going to be a source of confusion.)

~~

An OSC message has two parts.

• An address (for command) with slashes, e.g. /cs/chan/at/0.
• A list of arguments.
  • The argument list always has datatype tags, even if you don't specify them.
  • If you didn't write type tags, it will guess. In Pd, all numbers are floating-point, so outgoing OSC will format numbers as floating-point by default.
  • The X32 documentation says that it expects an integer 1 or 0. So, in [oscformat], you can force a number in a specific position to be integer-formatted by giving "i" as the type tag.

So...

Which.. for the message [set /cs/chan/select/47(, might make sense, because there's the 47?

No, it's not the 47. The 47 is part of the command path. How do you know it's part of the command path? Because it's connected with slashes in the device docs. The command path is totally excluded from the type tags -- it's always a string.

It gets a bit confusing with [oscformat] because the vanilla OSC objects write both the OSC address and the arguments as lists (no slashes).

• [packOSC] way: [send /cs/chan/select/47(
• [oscformat] way: [set cs chan select 47, bang(

OK, let's look at those.

  packOSC: 47 99 115 47 99 104 97 110 47 115 101 108 101 99 116 47 52 55 0 0 44 0 0 0
oscformat: 47 99 115 47 99 104 97 110 47 115 101 108 101 99 116 47 52 55 0 0 44 0 0 0

Notice that these are byte-for-byte identical. So these are just two different ways of expressing the same idea. (I do see in your screenshot where you're mixing and matching syntax, trying to use [oscformat] syntax with [packOSC] -- nope, this is not going to work. They have different programming interfaces.)

I suggest to slow down and do some smaller scale tests to make sure you can get the right result from the lighting board. Integration should come later.

hjh

@jbaker Just a little more info that might help, although you might already have everything that you need.
Anything in the string /x/y/z/etc is part of the osc header.... the address.
The data that follows..... that is then sent to that address.... /x/y/z <space> data ..... is the part that needs to be specified as i, f, s, b

The address string should always be comprised of symbols (even though parts may "seem" to be integers or floats) and problems can arise using vanilla [oscparse] when they are not..... so [fudiparse] and [fudiformat] can solve that problem as demonstrated here...... vanilla_bug_oscparse_solution.pd

Unfortunately quite a few devices send malformed osc headers.
MrPeach objects don't care.
David.

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

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.

@jbaker Just leaving it here it will be found, but if you can give it a good title and description (which will help people to find it when they are trying to accomplish something similar) you could post it under the "patch" section that you will see on the home page for this forum.
Well done....!
David.

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.

@jbaker said:

Success!

A-ha! Fantastic

I had a feeling you were just that close -- happy that you got it working.

hjh