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

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.

@whale-av said:

@ddw_music It looks as though the X32 requires a type tag string in osc messages, where the the data atoms after the message header /this-that are defined as integer(32) float(32) string and blob.

@jbaker ^^ this -- it means that your guess about putting slashes between all the parts of the message wasn't a valid approach.

@whale-av indeed, I thought it was a bit odd to have these long command paths with data in them. It definitely makes more sense with typetagged arguments.

hjh

There's an experimental 64-bit version of Pd

This is really orthogonal to 64-bit OSC timetags. This version just uses 64-bit floats as the underlying type for float atoms and samples. It does not magically implement the missing OSC typetags. Also, let's please call this the "double-precision" version, as "64-bit" typically refers to the CPU architecture.

Actually, there is no reason why Pd's [oscformat] and [oscparse] could not support the h (= int64) and d (= float64) typetags for sending/parsing OSC message. Of course, single-precision Pd would need to round the values down to 32-bit floats, but double-precision Pd could keep the precision (at least for 64-bit floats; 64-bit integers may still lose some lower bits when converted to 64-bit float atoms).

@mdiamond Yes, you can run the patch in the background using the command line switch -nogui
The terminal will not run at all and the patch window will not therefore be shown..... but will be running in the background.
The -nogui flag is added to the part of your script that starts pd...... not the line that opens the patch.

Sorry.... I did not post a patch...... yes... [notein] will receive your midi and the message I posted will use the note number it receives from [notein]...... replacing $1 with that number...... and send on the message you want.
Then you will need [oscformat] + [netsend] for pure vanilla...... or [packOSC] and [udpsend] if you use the MrPeach library.
So where I put [inlet] put [notein]
Where I put outlet put [packOSC] followed by [udpsend].
David.

@romulovieira-me It should be very simple using MrPeach.

If you are using Pd-extended you need [import mrpeach]
For Vanilla maybe [declare -lib mrpeach]

Osc messages need an address.
I have put /python...... it could be /test or /anything.
The address can be longer......
You could have for example /mixer/fader1 and then /mixer/fader2 ...... the address tells the receiver how to differentiate messages on the same port.

"send" tells [packOSC] that it is a message that it should send.

If your receiver (python) is on the same computer then [connect localhost portnumber(
If it is on another computer [connect IPaddress portnumber(
i.e. [connect 192.168.1.67 9997(

David.

Hey-ho........ I just noticed you posted your patch.
I have not changed it.... I just changed the objects to their basic names and it works for me........
patch.pd
MrPeach is usually reliable sending OSC bundles in the correct format.
OSC can be sent in various formats and it can be necessary to set the format for each part of a bundle..... so for /test 0.5 hello 2 using the new vanilla objects the format would have to be set as fsi.....float symbol integer
But MrPeach does that automatically.
I have never coded in Python though.

Hi.
I started recently using Pd on Ubuntu and I have some struggles.
Now I'm using 0.49 Pd version.
After installing the external, i.e. mrpeach, I can open the help patch and use it.
But.. if I restart pd, creating a new file and try to create a packOSC object, pd can't create it. Then if I open the help file everything is ok and I can create the object in every new patch.

What's wrong? Never happend to me, neither on Debian or Windows or Mac.

The strange thing that's it's happening is that everything I save (externals and patches) are always locked. I'm not the owner of the file.
So I think that there is an error about permission and installing process

Thank you

@elcraydo You should use [oscformat] and specify a float in the blob using the message [format f(
which must of course be specified before the blob is sent.
You must then use the -b switch for [netsend]
https://forum.pdpatchrepo.info/topic/11226/netsend/23

Using the old [sendOSC] it might work if you send the message [typetags 0( into it, and specify the incoming float eg........ [float 1.2( ........ although that should not be necessary.
It could be that processing does not support typetags or there is some mismatch with [sendOSC]?
[packOSC] and [udpsend] from MrPeach used to work well.
David.

Hey, I tried using float() but the problem is that the typetag is getting switched.
If I'm parsing for a message with "fff" and it turns into "iff", then I either need .get(0).floatValue() or .get(0).intValue()