@FFW @jameslo @FFW @jameslo @FFW @jameslo
a quick attempt,
updated 100 times

now with one repeating sequence, 2 seconds , 50 phasors in parallel, I am done now, good night

ppphasor~repeat.zip

@FFW This seems to work, but I can not quite see why yours does not work and I went through it removing every possible cause I could think of until I had pretty much this same patch, and it didn't work. Patch it together from scratch and it works, so probably something stupid and easy to miss in your patch and we are both missing the obvious. I added a third and fourth argument so you have shrunk width and hight and expanded width and height for args now and left some of the details for you to fill in.
ffw.pd

This seems pretty useful, easy way to make menus and dynamic interfaces, good idea to stick this in an abstraction, never dawned on me to do such a thing.

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!

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

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.

Thank you all.
@whale-av
@ben.wes
How would you implement the combinations formula (C (n, r) = n!/r! (n-r)!) in an efficient way? So that an n and r can be entered in and print all possible combinations?
I used the factorial expression object to calculate the combinations formula using- expr (fact($f1)) / ((fact($f2)) * (fact($f1 - $f2)))
What approach would you take to calculate the combinations formula without using the expressions object?
What approach would you take to calculate the combinations formula with using the expressions object?

Adding a List and or Array
How would you approach being able to add any type of customizable list/array (for example, list/array = A, B, C, D, E, F) and then telling the patch you want to generate any type of combination and then print all possible combinations?
For example, customizable list/array = A, B, C, D, E, F (n)
generate all possible combinations of 2 (r) also customizable
Print-
All possible combinations = 15
A, B
A, C
A, D
A, E
A, F
B, C
B, D
B, E
B, F
C, D
C, E
C, F
D, E
D, F
E, F

@jameslo said:

I'd still like to know if spaces are legal and possible with [oscformat] though.

I'm a bit surprised to see this, but in fact, according to the OSC spec 1.0, spaces are not allowed in OSC command paths.

https://ccrma.stanford.edu/groups/osc/spec-1_0.html#osc-address-spaces-and-osc-addresses

Each OSC Method and each OSC Container other than the root of the tree has a symbolic name, an ASCII string consiting of printable characters other than the following:

-character-	-name-	-ASCII code (decimal)-
’ ’	space	32
#	number sign	35
*	asterisk	42
,	comma	44
/	forward slash	47
?	question mark	63
[	open bracket	91
]	close bracket	93
{	open curly brace	123
}	close curly brace	125

So Pd has no obligation to support spaces here.

I suppose it depends on the software's OSC handler. SuperCollider doesn't complain (contrary to the OSC spec):

n = NetAddr.localAddr;  // send to myself

o = OSCFunc({ |msg|
    msg.postln;
    o.free;
}, '/test space');

n.sendMsg('/test space', 1);

prints: [ /test space, 1 ]

I did some other tests:

• "symbol patch 1" --> [list fromsymbol]: escape char 92 is not in the ASCII list.
• list "112 97 116 99 104 32 49" --> [list tosymbol]: resulting symbol prints with a backslash. I don't know if the backslash is stored internally, or if it's inserted only for the printed output. A quick look at the source code in x_list.c suggests that the backslash is not stored internally.
• list "112 97 116 99 104 32 49" --> [list tosymbol] --> [list prepend set] --> [list trim] --> [oscformat]: The printed bytes from oscformat do include char 92. But I couldn't see in the source code where the space is being escaped. (This long way around to build the "set" message is to be certain that there's no backslash in my input -- the backslash must be generated internally somewhere..)

So [oscformat] seems to be where the problem is happening -- but the OSC spec makes no promises that spaces will work, so there wouldn't be any justification to log a bug.

hjh

@whale-av said:

I am almost certain that Gui objects in TouchOSC can talk midi and OSC at the same time.
But I doubt that it will communicate over wireless (required for OSC messages) and USB at the same time.

GUI objects in TouchOSC can send Midi and OSC at the same time, and wired USB connection does work for both, no issues. no need for having the iPad on Wi-Fi. just takes a while for TouchOSC on the iPad to realize what the IP address of the laptop is.

The communications between Pd and touchOSC are set in the abstraction [osc-s-r] within the [globpitcharray1] patch in the zip I posted.
There is a TouchOSC layout plom.touchosc in the zip that should be used with this patch (for a test demo).

thanks for breaking this down for me!

You would need to fix the IP address of the Ipad (static address) and use that address for [netsend] and [netreceive] in [osc-s-r] ....... if you ever get over your fear of using Wi-Fi for this.... or just feel like trying it to see what it will do.......

yes, [osc-s-r] is definitely where it's at. thanks for spelling out the [netsend] and [netreceive] to me, cos looking at the screenshot i had, i can now realize where to input 11000 and 11001 for send + receive. the connect portion of the script was throwing me.

i hope i have it right now,

I've written a VST3 plug-in using Camomile+Pd to output groups of control change messages in response to OSC commands. The CC messages are used to turn channels of a Yamaha 01V96i mixer on and off.

On Windows, everything works fine, but on my M2 Mac I'm having strange issues. The plugin receives OSC fine but the MIDI CC it generates is zeroed-out, e.g. when I ask it to send B0 48 7F, the mixer receives B0 00 00. I can run the Pd patch standalone on the Mac and it works fine.

The AU version of my plugin doesn't output MIDI at all and I get an OSC error message in the Camomile console. I tested a different CC generating Pd/Camomile/VST3 plugin on my Mac and its CC messages are also being zeroed out. In contrast, I've written two other plugins that work fine on the Mac: one is a side-chained envelope follower with adjustable release time and the other generates 5 channels of audio in response to OSC messages.

I saw a somewhat old discussion on the Camomile Github site referring to some issues with MIDI CC under VST3 (https://github.com/pierreguillot/Camomile/discussions/260), but I don't recall having issues like this on my old Mac with my CC-generating plugins hosted in REAPER circa late 2020, and I don't see any similar complaints in discussions about PlugData, which I believe uses Camomile under the hood. In case the issue was REAPER, I tried to load the plug-in to Audacity, but Audacity complains that the plugin is incompatible.

I think there's probably a better way to achieve my end goal but wanted to check in with Pd brain trust because I'm sad to think that I've lost this capability. What would you try next?

I'm using REAPER 6.81 as the VST host, Camomile 1.0.7, Pd 0.54.0, and MacOS 12.6.7 on last year's M2 MacBook Pro.