@FFW said:

[netsend] help for the [send( message says "same as list" so you can also do

[hslider]
|
[list prepend z]
|
[netsend]

Yes, that's how it works too.
pd2py_v3.pd
For less computational effort, is one preferable to the other, or are they equivalent?
Thank you,
a.

[netsend] help for the [send( message says "same as list" so you can also do

[hslider]
|
[list prepend z]
|
[netsend]

@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

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 older Pd vanilla is silent in the console but 0.55.2 clearly states that UDP [netreceive] cannot send return messages on the same port.
Further investigation required.

So, as there is more help in pd 0.52.2 what you need is the left part of this..... 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(
........ netsend-receive-help-mod.pd ... see [pd send-back-in-UDP] at the bottom left.

The original help specifies separate ports...
So it is not certain that it will work.... the data might only bounce back, but might go through to the X32 at the same time...? But it could fail to connect to the X32 at all.

After more testing....... pretty sure that the X32 will receive the sent data and you will receive back on the same port...... but that the data you send from Pd will also be reflected by the port.

Note that the "send" prefix is no longer needed for a list.
David.

@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

@jbaker I am not sure that the return data is working with udp....... [netsend -u -b]
Maybe try a tcp connection..... [netsend -b]
David.

@chvolow24 said:

@ddw_music said:

Lack of handshaking means (AFAIK) UDP doesn't have a concept of sending back to the originating location.

This actually isn't true. The first two bytes of a UDP datagram specify the source port, and the encapsulating IP packet includes the source address.

Yes (and this info is available e.g. in SuperCollider, where every received message is accompanied by an address object indicating the source).

It is still profoundly weird to me that one would send a return message by passing a list to netreceive, and receive it in netsend. There may be some reason in TCP why that's necessary, but wouldn't surprise me if such an inversion were unnecessary in UDP. I would just use netreceive for receiving and netsend for sending, and be done with it.

hjh

@chvolow24 said:

What would prevent the responses from being received, output, or printed by netsend?

UDP is a dumb protocol: no handshaking, no confirmation of message receipt -- it's "I sent it out the port, then we just hope for the best."

Lack of handshaking means (AFAIK) UDP doesn't have a concept of sending back to the originating location. Because it's dumb, it's simpler: [netsend -u] only sends, [netreceive -u] only receives. The idea of passing a message into [netreceive] and it being sent somewhere doesn't make sense in UDP land.

In the helpfile, the "send back" functionality is demonstrated for TCP connections but not for UDP. I don't think this is a casual omission -- I think this actually reflects the functionality.

hjh