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