@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

@ddw_music Thanks for your reply!
About the two possibilities:

• No configurable port for receiving or sending

• Yes- I agree! That wouldn't make sense for the X32 to reply on a random UDP port.

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.

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

I'm not 100% certain. Yes, the LiveToolKit x32 software is running on the Pi and can read the OSC messages from the X32... But if Pd chooses randomly the receive port with [netsend]... Should I just use a [netreceive (port#)] object? But I see what you're saying about the firewall. I'll try SuperCollider (thank you, more tools are always nice) and see what happens... Thanks for including that screenshot of SC to get me started!

Tilda's: Fair enough! I got the idea in my head from the X32 OSC documentation.

Will reply here with what I find... Thank you both very much!

@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

I should add that using fudiparse works fine:

[netreceive -u -b 5400]
|
[fudiparse]
|
[unpack %f %f]

My expectation was that the above patch was equivalent to this:

[netreceive -u 5400]
|
[unpack %f %f]

But the latter does not work now.

@rph-r You can use [netreceive] in the installation patch.
Then use [netsend] in your remote patch.
Once your remote patch is connected you will be able to receive messages back from the installation through those same objects (see the help files).

If you use a tcp connection in [netsend] and [netreceive] then the left outlet of [netsend] indicates whether it connected (the value will change from one to zero when you try to send a message if the connection has been lost).
That is because the TCP protocol needs an acknowledgement packet sent back, or it will send the packet again..... and again until it times out. UDP will not do that.

If you need an "alarm" that the connection has been lost, or that the installation patch has stopped sending messages, then add a [metro] sending a ping back to [netsend] from the [netreceive] in your installation patch.

Then you could set up an auto reconnect in your remote patch.
You can only "find" another computer on the net if its IP has changed by using DNS lookup, and if an address changes it can take up to 2 days for all the worlds DNS servers to be updated.
Maybe something like DynDns is quicker, but if you are instigating the connection using your controller (remote) computer then you don't need that anyway.

You will always be able to reach the installation computer from any internet address.
David.

P.S. of course you can set up and test on your local network before implementation.

Hallo good people
I have already searched the relevant forums, and the TouchOSC manual but I am still struggling to get OSC data into Purr Data.

I am able to successfully parse OSC data from, for example, Sonic Pi into PD (via localhost) on the same machine. I have recently installed TouchOSC on my Android tablet, and installed Protokol (network messaging monitor) on my MacBook. All the OSC messages from TouchOSC (tablet) show up inside Protokol (MacBook), but [netreceive -u -b], [listen 800( in PD shows nothing. Do I need to tell [netreceive] where the OSC data is coming from (the connect 192.x.x.x message doesn't work)?

I'm afraid terms like Host, Client, server etc mean nothing to me, so is there a step by step guide out there for my issue please?

[EDIT] Muppet - I had to close Protokol!! All working fine now. Told you I was a n00b :D
<3
Brendan

In the PD patch provided with the script you should have a [netreceive]. It has to be trigger in order to listen at the port the py script attempts to send to.
See [netsend] and [netreceive] help.

EDIT: for ref, the py script come from https://github.com/eoinfennessy/webcam-theremin/

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

@zerino You need a patch open with a [netreceive] object in it and connect the left outlet to a [s pd] like,

[netreceive 3000]
|
[s pd]

Then from the command line you send a command like echo open filename.pd $(pwd)\; | pdsend 3000 and it will open filename,pd, this assumes you are in the directory which the file is in, the $(pwd) command can be replaced by a path. You should be able to setup your file manager to do all of this automatically but I am not familiar with if, or an alias in your .bashrc or the rc of whatever shell you use, for bash alias pdopen="echo open $1 $(pwd)\; | pdsend 3000"

Edit, we can not actually use an alias like that in bash, but we can make that a function, just put this in your .bashrc instead of the alias. Need to run source ~/.bashrc in any open terminals or logout/log back in for it to be usable. Then just run pdopen <filename> and it should work.

function pdopen () {
   echo open $1 $(pwd)\; | pdsend 3000
}