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

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

@ddw_music said:

@porres Did this make it into your documentation branch?

Sorry I missed this. I've only recently started tracking this forum more closely. So, to answer you, no, this did not make it into my docs revision. I mean, I revised this help file of course, but didn't have a problem with it.

You could have opened an issue on github or something the https://github.com/pure-data/pddp repository was created just a bit over 3 years ago (nov 24th 2021). This post is "3 years old" but there is no precise date, so not sure if you knew it by then... and well, here it is for everyone to know about it in any case.

@Jona said:

@whale-av I wonder, why "they" dont add those corrections to PD vanilla?

well, who's "they"?

The Pd-extended project was simply an independent development on a fork of Pd and the whole documentation did include particularities of its own, meaning that it referenced to other objects and things that were particular to Pd extended, so not that easy and simple to apply and adopt. Also, in some cases, I found issues and things that were not really accurate, arguably wrong in the Pd-extended docs.

I don't really know what was happening or how it happened as I wasn't that involved back then. I'm curious to know but not that curious to investigate, search the list archives and stuff. But I can make assumptions.

Maybe no one really just bothered in helping with and collaborating to the Pd docs. And I say that because at one point I just started making lots of changes and contributions to the Pd Vanilla docs and there was simply no discussion or resistance. I eventually started getting more comfortable in changing more and more things and was simply trusted and, well, after many many years I basically rewrote the thing and have been working on a manual overhaul this year and whatnot.

I kept hearing people complaining about the Pd docs, and saying how the Extended documentation was so much better. This kept going on after extended simply died and there were forks based on it... and... well... I just decided to do things, take actions, instead of wondering around

So, why weren't "they" doing things? There was no "they"... there weren't just people actually getting involved to collaborate.

Instead of "they", there's always been "we"... this is open source and a community based project. Somehow actions got fragmented into independent efforts, not well coordinated, sometime conflicts did arise. Funny enough, many of the people in this community did not realize they were or could be a part of it and internalized the paradigm of just being "users", while "developers" were anonymous god like entities that were seemingly on another spiritual plane that we could not communicate to and just wonder about how and why "they" did or did not do things

Or maybe, somehow, people incorporate the non open source mentality, where "we" are users and "they" are the unknown paid workers that are working on the company that develops the software.

I did promote a documentation overhaul and posted about it in many channels, asked for collaborations. Anyone (really, anyone!) can do things, propose changes and improvements to the docs... it's open source folks. I haven't been doing it "all by myself". We often discuss how to document some things, it's gotten a little better, but I'm mostly doing this alone, by myself, and pushing it. Practically nobody came up to join me and collaborate and help with the documentation overhaul...

So... that is to say I will see about adding more details to [atan2] and would love to hear actual suggestions about how WE should do it

cheers

@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

@esaruoho said:

if it helps, i'm trying to simulate tuning forks, or an acoustic instrument, well, not simulate, but the "release/decay" portion of it. i.e., "die after 5 seconds" or "die after 15 seconds".

Sounds like a job for a decaying filter. I did this a while back.

0606-decay.pd

Edit: The patch says the energy doesn't have to be an impulse, but if it's longer than an impulse, energy will accumulate above 1.0 and then take longer to reach silence. So for enveloping purposes, the one-sample impulse makes the most sense as a trigger.

Edit 2: If you take two of these rpoles, one with a longer decay time and the other with a shorter time, and subtract longer - shorter, then you get a nice smooth attack-decay envelope (Decay2 in SuperCollider).

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,

@esaruoho said:

I could try again, but it looked like UDP required me to know the IP address of both the laptop and the iPad, and that really threw me (i don't know how to figure out what the IP address of the iPad is, or how to make sure it's always the same, same for macOS).

Ah right, for bidirectional communication.

Actually in the netreceive help file, there is a flag for this: "optional -f flag for from address & port outlet (0.51+)".

Help file example prints from: list ::ffff:127.0.0.1 57120 where ::ffff:127.0.0.1 is an IPv6 address.

So...

... should configure the [netsend] to send to the first address from which messages were received (and I did a quick test, which worked). If you enable "Ping" in TouchOSC, then it will automatically send a message to the computer, which will trigger the "connect" logic right away.

Incidentally, I didn't know about this feature (never used the "from" address in Pd). My thought process was, "Well... this is a very common requirement, so let me have a look at the [netreceive] help patch and see if there's anything about 'from'" -- and toward the lower right, there's a [print from] box. Hm. Then, what's different about the [netreceive] feeding it is that it isn't only "-u -b xxxx" but rather "-u -b -f xxxx"... what's that "-f"? Then, looking up from there a little bit, there's a list of object creation flags, where "-f" is explained.

So the solution exists, and documentation for that solution is actually reasonably clear.

i have maybe an hour every 2-3 days to try and get something going, and also feel a bit like there's no "TouchOSC with PureData for idiots" blog-post for iPad / macOS going on, or at least i haven't been able to find it.

This I fully understand.

Pd OSC sending, like this. It won't send anything until after you push a connect ip.ad.dr.ess port message into the netsend inlet -- as noted above, you can get the parameters for the connect message from [netreceive].

... producing messages like /1/toggle1 1.0 or /1/toggle2 0.0. This type of message format is what you need to change a control's value on the tablet.

It's also possible to "set" the OSC command path before providing the arguments -- but try the simple way first.

hjh

@whale-av said:

@esaruoho This being a new thread I had forgotten that you were using a wired USB connection.
Yes, that means that you are limited to midi only.

Is that really true? I used to use TouchOSC on an Android tablet. I could connect USB to the computer, and then on the tablet, open a tethered network connection, and this would assign a new IP address to the computer. Then I could use the IP address in TouchOSC and it 100% worked for OSC.

Unfortunately that feature has been removed from the Android versions on my current devices (but these are skinned Android forks, not "real" Android, so the feature might still exist). For iOS: https://support.apple.com/en-gb/guide/iphone/iph45447ca6/ios

Connect a Mac or PC to your Personal Hotspot
You can use Wi-Fi, a USB cable, or Bluetooth to connect a Mac or PC to your Personal Hotspot. Do one of the following:
...
Use USB: Connect iPhone and your computer with a cable. If you receive an alert that says Trust this Computer?, tap Trust. In your computer’s network preferences, choose iPhone, then configure the network settings.
...

After that, the Mac should have an IP address that directly connected to the mobile, through the cable. There's no reason at this point TouchOSC would be prevented from sending and receiving OSC messages (while allowing MIDI...? that doesn't make any sense).

@esaruoho

"just not sure how to get PD and TouchOSC to talk to eachother so that this would work."

The first thing I teach in my class about getting data from an external device is: print out the data so that you understand what's coming in.

This goes for MIDI, OSC, Arduino, computer vision packages -- you can't do much of anything without knowing the format of the messages coming in.

You should get print outs something like:

print: list 1 fader1 0.777236

The specific keyword and number of arguments will be different for the multi-slider, but you can find that out by reading the console window.

The real message coming from TouchOSC is like /1/fader1 0.777236. [oscparse] splits the command path /1/fader1 into separate symbols. ([mrpeach/unpackOSC] doesn't do that -- from this object, you would get print: /1/fader1 0.777236.)

At this point, with [oscparse], you will run into the problem whale-av mentioned: 1 in the printed message is a symbol, but if you try to match it using [route 1], it will fail because [route] will be looking for a number. That's the workaround I posted: [oscparse] --> [fudiformat] --> [fudiparse] --> ...

Then the other detail is that you need to drop the list type tag before routing.

And [route] will give you the argument values, now split into one dataflow pathway per control.

hjh