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

Btw from jbaker's screenshots:

• Pd is definitely receiving a message from SC sent back to the Pd port, on the local machine (so, netsend isn't the problem).
• SC is receiving a reply back from the X32, confirming that the X32 is sending back to the originating port.
• But Pd netsend seems not to be receiving on the same port from the X32.

One difference is that the Pd vs SC test was on localhost, hence nothing to block traffic. (Why wasn't the X32 reply blocked for SC? SC doesn't randomize its outgoing port.)

I still think something in the OS is blocking the messages from the X32, but only for Pd.

hjh

@jbaker said:

I think you're right about the python script... I've finally looked.
It looks like it's sending OSC to 10023, and...it kind of looks like it's receiving on port 1024..? I'll try a [netreceive 1024] object and see what happens.

Python docs say that the number given to recv is the size of the receive buffer, not the port.

The snippet from the X32 docs that you posted is unambiguous: replies are sent back to the requester's IP and port. So the netsend right-outlet approach should be correct.

Everybody gets their head tied in knots over send/receive ports.

When you connect a netsend, this is giving the IP and port TO which messages will be sent: TO port 10023. The message packet itself contains the sender's IP and port. In Pd, the FROM port is chosen randomly and AFAIK there is no way to know it -- so there's no way to open a netreceive on Pd's sending port. So let's say Pd chose port 45227. You send a message to the X32 and the packet includes your computer's IP and port 45227. The X32 (per documentation that you showed) should send its reply to the computer's IP and port 45227, where it would come out the netsend's right outlet.

I'm still suspecting firewall here. You said it's working on the Pi -- if the Pi isn't running a firewall but your computer is, that could block incoming messages.

"Suspecting" may be too strong -- at least, it's necessary to rule that out. (One not-so-ideal thing about Pd's use of random port numbers is that, in this case, you'd have to open a wide range of ports, or disable the firewall. If you could specify Pd's sending port, then you could open only that port in the firewall... but you don't know which one to open, so you'd have to open thousands of them.)

@whale-av

just the [netsend] on the left of the screenshot below........ it must be told to use the same port for send and receive...... so [connect port sameport(

That doesn't sound quite right to me. Pd here should send to 10023, but it will be sending from a port of its choosing, which isn't 10023. The X32 is sending back to the originating port (not to its own receiving port). So I think "connect aaa.bb.cc.ddd 10023 10023" would not work. The replies from the X32 will not be going to port 10023 on the computer.

hjh

@jbaker said:

@ddw_music I'm guessing that the X32 isn't replying on the same port we're sending to (with pd), but that's also an assumption.

There are basically two possibilities here:

1. The X32 sends its replies to a port of your choosing. If that's the case, then there must be a configuration option for "port" somewhere on the X32.
2. If there isn't place to configure the port, then it would pretty much have to be sending back to the Pd sending port. (It would make no sense to send to some arbitrary port that you have no control over and that is different from the sending port.)

That Python script should tell you whether it's receiving OSC on the same port from which it's sending, or on a different port.

One other thing to check -- are you 100% certain that the Pd machine's firewall is not blocking high port numbers?

When you "connect" a [netsend], the port number specified in the "connect" message is the port to which messages are sent. The from port (Pd side) isn't specified in this message, and (AFAIK) it's chosen randomly. If you have a firewall that allows traffic on only a few specific ports, that could be a problem for randomly-chosen ports.

The X32 Live Toolbox is receiving, but maybe that's operating on a specific port that was previously opened in the firewall.

You might also try SuperCollider for a test. SC by default sends and receives on port 57120. So you could test "reply to same port" like this:

n = NetAddr("10.136.124.112", 10023);

OSCdef(\ch02, { |msg, time, addr|
    msg.debug("got it");
}, '/ch/02/mix/on');

n.sendMsg("/ch/02/mix/on");

... and if the X32 replied to the same port, you should see "got it: [ /ch/02/mix/on, 1_or_0 ]" in the console window.

Whenever I try to send pd messages with tilda's I get errors though.

Don't. [oscformat] handles that for you.

@whale-av

I am not sure that the return data is working with udp

It does, actually. addr.sendMsg at left tells SC to send back to the Pd port where the message came from, and it comes through [netsend]'s right outlet just fine.

hjh

@whale-av said:

@ddw_music It seems that maybe data can be requested from the X32...

With apologies but why do you keep addressing these to me? It's not my device or my question.

I was trying to fill in some gaps for jbaker about how to use the Pd OSC objects. My interest ends there, tbh.

hjh

For testing purposes here, you have two [print reassembled] -- meaning that you have no idea which one is printing. If you give them different names, the console window output will be less confusing.

I'm pretty sure [netreceive -u -b] isn't doing anything because it hasn't opened a port.

[oscparse] does not give you /ch/01/mix/on -- it gives you ch 01 mix on -- which has to be peeled apart by multiple [route] objects. Then there's the fun thing about numbers in OSC command paths. So I'd suggest:

Because the device has numbers in the path, you have to use the [fudiformat] / [fudiparse] workaround. Don't worry if you don't understand why, just, do not delete them.

(The netsend right outlet thing is based on the assumption that the device is sending back to the same port that Pd sent from. This might not be true -- in that case, you'd need to find out how the device is sending and configure the patch accordingly. Also double check to be sure the firewall isn't blocking Pd from receiving.)

hjh

@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

@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

@jbaker said:

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.

I think the receiving bit should look like this:

If I send back to the same port e.g. /hi/back 1 then, after list trim, the message looks like hi back 1.

[fudiformat] / [fudiparse] is a workaround to handle the numbers in the OSC path.

BTW those "send /xxx/yyy/zzz" -- pretty sure that's not standard OSC -- I crashed SuperCollider trying to send to it that way.

This is the right way to send a properly formatted OSC message. Leading zeroes can be escaped, e.g., set ch \02 mix on, bang would send /ch/02/mix/on.

hjh

@jamcultur said:

I'm creating a wavetable using sinesum to write harmonics to an array, which works fine for integer overtones. I'd also like to be able to be able to write non-integer overtones and undertones to the array.

If you put a 2.5 cosine harmonic into an array (2.5 cycles spanning the array's length), then the beginning of this wave will be +1 and, at the end of the array, -1. So you'd get two full cycles, then half a cycle going down, and then jump abruptly to the start again. So, non-integer partials will always behave like hard sync.

If you want that hard sync sound, that's fine, but if you want a smooth wave at 2.5x the fundamental frequency, it's not possible with a wavetable (unless you size the wavetable according to the LCM of the partial ratios and scale all the ratios up to be integers).

hjh