@kazeko I did a bit more work on it here....... https://forum.pdpatchrepo.info/topic/14240/pure-data-and-pi4-with-usb-audio-interface/12
As so often, it might be hard to remember how it works, but I think I designed it to select an interface automatically (by name rather than the position in the Pd Media tab list) as a patch was opened.... but it needs the external [audiosettings] from the mediasettings library.
It seems that the librarywas available for the RPI4.
David.

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

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

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

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

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

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

@RT5000 You will need to use a "Number 2" box from the put menu..... which is a GUI.... whereas a simple "number" box is not.
Message...
[;
receive-symbol pos x y(
David.

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

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