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.

Hi, so I'm somewhat new to PD and I'm trying to make a sequencer for the Befaco Lich. I'm adapting the sequencer used in this video:

What I want is to simply have two sequencers with pre-made sequences that I write in PD, and turning a value knob to switch between the sequences.

I've actually gotten somewhat far but a problem I can't seem to solve is a way to prevent a number box from refreshing my toggles whenever there is any activity, even if the int it's feeding into doesn't change. This is what happens (basically toggle/bang flutters on and off instead of stays at its value for its current position)

I've really gotten stumped here, but once I'm able to switch between patterns in the sequencer then I think I can make the rest. One other thing was for the outputting triggers - when an active step emits a bang, that bang needs to send a burst of CV out the Lich's gate output to make a trigger. Would a burst of white noise work? I realize I have to route it to the hardware but I'm confused what kind of signal I should be making. Thanks for any help that can be provided.

@atux No need for MrPeach with that patch.... all Vanilla.
First step in Ardour...... maybe use debugging... here....... https://manual.ardour.org/using-control-surfaces/controlling-ardour-with-osc/osc-setup-dialog/ .... to see whether any messages are being received..... "log all messages"

Also try removing the -b fflag from [netsend]...... i.e. just [netsend -u]

Pd can receive messages back on the same port..... so forget the port setting to 7777.

note for self...
Looking at that page Ardour is expecting messages (of course) from another computer or tablet, but the receiving port must be on the localhost so I don't think that is the problem.
It is definitely UDP.
David.

@atux You seen to have a problem with paths..... maybe you have had numerous versions of Pd installed in different places..... this might help..... https://forum.pdpatchrepo.info/topic/11974/external-does-not-load-anymore/12

Here is a new try for the OSC messages..... sending just the headers... might work..?
I am assuming that Ardour is on the same computer.... .and is a later version than 4.7
osc-ardour.pd
David.

@atux Give this a try and let me know....... osc-s-r.pd
David.

AArgh.... I was happily reading osc messages for Ardour 4.7 and they have changed the message system so [oscformat ardour] might need to be changed...... I will update if I can find what the message address should be with the new "banking"..... whatever that means...

But maybe just try removing "ardour" if it doesn't work..... i.e. [oscformat] only.

On my system in Pd 0.54.1 the MrPeach library will load just by putting the full path in Path preferences... without [import] or [declare]...

@atux If you want to send messages to Ardour..... controlling it from Pd.... this is the page you need...
https://manual.ardour.org/using-control-surfaces/controlling-ardour-with-osc/osc-control/
OSC messages can be sent back to Pd from Ardour too....
The patch you posted first controls plugin parameters.
Probably just replace the send message with for example.......
[send /transport_stop(
or
[send /transport_play(
David.

Is Perfection Important?
Exploring the Sound through the Fibonacci Sequence

Application deadline: Nov. 18, 2023, 12am
Submission Email: lyd15150099208@gmail.com
Website:https://www.yadong.uk/process-2-1/event-one-jn7aa

Music and Data Convergence: A Call for Creators

The intersection of music and data offers a realm of boundless possibilities. Both fields rely on precise symbols to convey information, creating a parallel between musical notes and data records. Just as performers and listeners immerse themselves in the musical experience, data enthusiasts observe and record the ever-evolving world of information. In this context, stages and instruments become the equivalent of facts and observations, bridging the gap between music and data.

While music and data aren't identical systems, music can be seen as a unique way to represent data. It's not just about recording and playing notes; it's about reimagining music from a data perspective. Our goal is to unlock infinite possibilities, sparking creativity at the intersection of data and music.

Open Call: Crafting Perfection with the Fibonacci Sequence

The Fibonacci sequence, a mesmerizing pattern found in nature and the arts, offers an exciting creative opportunity. Starting with 0 and 1, each number in the sequence is the sum of the two preceding numbers (1+1=2, 1+2=3, 2+3=5, and so on). This sequence often leads to the golden ratio (approximately 1.618), a cornerstone in creating aesthetically pleasing designs in art and architecture.

I invite artists, musicians, and visionaries of all levels to explore the potential of this sequence in crafting perfect sound art. Use the data series that represents perfection to create works of sonic wonder.

If this piques your interest, please share your artwork or ideas with us via email. We'd love to hear about your creative process and vision.

Selected works have the chance to be featured in our upcoming online exhibition.

Join us in the exploration of data and sound, as we redefine the boundaries of creativity at the nexus of music and information.

@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