Ah, that makes sense with the mother patch (and the fact the variables need to be created at load time). I am maybe approaching my problem from the wrong angle in that case. I have a simple abstraction that will receive an OSC message from Open Stage Control, and I want to reuse this over and over, so currently adding the OSC address as a static variable in the abstraction name and that works really well.

As I am trying to create a sort of modular in pure data, I wondered if I have two identical for example 'envelope' abstractions (with controls pre-mapped to OSC), then it would be fantastic to make the OSC addresses dynamic (so /EnvAtt_1 could be /EnvAtt_$3), and I could have a floatbox define the $3 on each copy of the envelope abstraction.

So inside my OSC control I have declared the OSC address in its title and then use this in a receive, but the issue is declaring a dynamic variable in a receive path (that is not from the abstraction name), so 'r EnvAtt_$3' for example. Can you declare a variable for a receive any other way?

Sorry for the convoluted reply, and thanks again for helping, much appreciated!

That's rather ambitious indeed. I don't believe you'll be able to display the actual patch. Even if you want to only display knobs and other widgets, you'll have to code this interface yourself and control Pd, or have Pd control those, by sending values for these widgets via OSC.
If I understand what you describe, you want to create a graphical user interface to control a Pd patch, right? If this is so, then what I wrote about holds.
You could try to find some library (it would probably be Python or C++) that creates widgets for OLED displays, and use that together with OSC, but the API you'll use should support OSC communication.

@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

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:

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.

@whale-av I've watched that thought pass by, but haven't pursued it (I don't remember why). It's worth a shot- I'll try this and report back.

When I send OSC commands to the lighting board in this patch, it works fine. What's interesting is that the lighting board has a configurable OSC* send* port and configurable OSC receive port (8004 & 8005 if I remember right). But after reading documentation again, it looks like the X32 board receives and sends OSC on udp- not that I won't try TCP. In the unofficial OSC doc I read this...

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

@jbaker said:

So... I'm trying this and not seeing any messages print.

You need a bang.

OSC's "normal" case is to send many messages with the same command path, with different argument data. So, oscformat sends only when receiving data values in the inlet.

To send a data-less OSC message, command path only, use a bang instead of data.

To make that more convenient, use Pd's messaging logic to bang automatically:

So any message you send into the [pd] subpatch will do "set" then "bang."

Is the 57120 a common udp return port for OSC devices?

Well, I don't have your device, so I wasn't testing on the same port.

Everything above is totally independent of the port number.

hjh

Hello,
I've been working on this for a couple years now... I'm very close!

Hardware: Raspberry pi 3B
OS: Bullseye, pd .51
Peripheral hardware:

• Behringer X32 audio board. Physical and network MIDI out, can do OSC over MIDI sysex (osc documentation link)
• Colorsource AV board, can be controled via OSC

Here's my patch

Goal: When any of channels 1-4 are unmuted on the X32 audio board, a DMX light turns on (has 'on-air' stencil and a red gel attached to the front). When all 4 channels are muted, the light turns off.

The problem: This works- the issue is that sometimes pd or the X32 will mess up and a MIDI message is missed, so one of the 4 mute toggles (in pd) will be the opposite of what the actual mute status is of that channel.

My idea to fix: "Ask" what the mute status is of each channel every 10 messages or so.

Overview: I found the MIDI that the Behringer X32 spits out when muting channels, then used 'sel' to start, bondo sums and when the total gets to 4, an OSC message is sent to the lighting board to turn on the ON-air light. When it dips below 4, a message is sent via OSC to turn the light off.

I can't seem to get return values from the X32. With the X32 livetoolkit software I know that sending [/ch/02/mix/on] will return [/ch/02/mix/on ,i 1]. The send command doesn't need a value type (float, int, etc.), but the return value contains an int, which is either 1 or 0, which represents the mute as on or off. I can't get any return values from the board. I'm trying UDP with netsend -u -b 10.136.124.112 10023.

Also- I'm getting MIDI to the pi with the... UM-ONE midi to USB dongle. I forget the manufacturer but I think it's pretty common with Pi's and Pd.

If someone has a better idea that to achieve what I'm trying, I'm good with that too!

Any help would be appreciated! It feels so close and this will be my first 'new' thing I've made.

Previously been using an older MacBook Pro with OSX 10.10, and PurrData, all good.

New MacBook Pro M4 Max, and PurrData v2.19.3 from here... (2.20 was reported as damaged by the OS)...

https://github.com/agraef/purr-data/releases

PurrData v2.19.3 and v2.19.2 work fine, but there's no audio coming in from ~adc.

Opened a DAW, Reaper, set the input channels correctly, and there's audio coming in - to my new MacBook Po M4 Max. So the audio interface - a MOTU, is fine, and set up correctly ...it's just PurrData - there's nothing coming in from ~adc (I tried hooking up all input channels ~adc 1 2 3 4 5 6 7 8, and still nothing). Otherwise midi flows back and forth ok, and audio is sent out to the audio interface (via ~dac), but ~adc is dead ...and just to reiterate Reaper hears the input on those channels fine - but PurrData doesn't.

The audio properties in PurrData are set up fine, the audio interface selected, and multiple channels - so all good there (and I've using PD for many many years).

Anyone come across this - what to do?