I expect [netsend -u] to write responses from the server to its right outlet, but it isn't working. I've confirmed that 1. the messages are received by the server, and 2. the server responds correctly (other applications can receive and print responses). lsof -P | grep UDP | grep pd shows that pd is indeed listening for a response.

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

@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 am trying to send OSC from PD (to Sonic Pi), using the [netsend 1] object, it isn't working and I suspect the issue is with how I'm using that object. I have succesfully tested OSC within Sonic Pi (sending it out, then getting it back, all within SPi) and it works fine. receiving OSC in PD requires parsing from symbols to floats, but the helpfile for [netsend] simply shows, for example [send foo $1(.

#X text 21 10 Sonic Pi listens on port 4560;
#X msg 98 77 disconnect;
#X floatatom 209 120 5 0 0 0 - - -, f 5;
#X obj 153 155 * 0.01;
#X floatatom 62 299 5 0 0 0 - - -, f 5;
#X floatatom 143 120 5 0 0 0 - - -, f 5;
#X obj 155 261 print;
#X text 27 328 1 = port opened;
#X msg 119 189 send play \$1;
#X obj 62 256 netsend 1;
#X msg 23 38 connect localhost 4560;
#X connect 1 0 9 0;
#X connect 2 0 3 0;
#X connect 3 0 8 0;
#X connect 5 0 8 0;
#X connect 8 0 6 0;
#X connect 8 0 9 0;
#X connect 9 0 4 0;
#X connect 10 0 9 0;

Thanks
Brendan

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

@whale-av thank you so much. I have contact with the devs but I try to wait asking for favours until I have a decent understanding... as I do not want to strain you guys too much either... its a balancing act.

Unfortunately mrpeach is not available through deken, says "no matching packages for your architecture". Im on a Mac M2 with 12.5.1 Monterey that comes with the robot.

Status at the moment:

I can trigger from the browser and from terminal/zsh with curl.

I have not managed to get [netsend] to work. Tried some combinations with list and symbol. If using tcp I lock out terminal and browser triggering on that port/socket(?) (8000) . Using [netsend -u] (UPD) allows me to continue using terminal/zsh or the browser for triggering. My conclusion is that it would work if could format the message in the right way. But I do not know how the message looks when/if it arrives at the Ikaros WebUI. Can I monitor this in some way?

Now I will try using [command] to see if that works.

EDIT:
This works!! thanks @oid for getting me into [command]!

Now the next step will be to try to control parameters.

My goal is to be able to change the slider parameters of the robot/web ui from Pd by some sound process on the same computer locally. So no plans for connecting over internet at the moment.

@cfry said:

Thanks for replying.

if I want to send this command through [netsend]

http://127.0.0.1:8000/command/SR.trig/1/0/0

How should it look in Pd/[netsend]?

I can open the connection with [connect localhost 8000(

but sending

[list command/SR.trig/1/0/0(
or
[list command SR.trig 1 0 0(

does not work. I am formatting the ip adress wrong I think.

Hi,

I am trying to control a robot using HTTP requests. I would like to use [netsend] to send messages from Pd.

Trigger a recorded motion using HTTP requests

This can be done by making an HTTP request to the ikaros web server.

http://127.0.0.1:8000/command/SR.trig/X/0/0

X is the sequence. 0 Is the first sequence.

The local IP number 127.0.0.1 can be replaced by an assigned network IP.

If I write in the web browser address bar it works fine but I have not managed to get [netsend] working. I do notice that by sending [connect 127.0.0.1 8000( it seems connected but I think I am sending messages that are not formatted correctly. How should they look in pd?

Thanks!

Hello everyone

I've created a Pure Data patch that successfully receives OSC data from a Processing sketch. However, I'm struggling to send OSC data back to Processing using the native object netsend, without relying on the outdated "mrpeach" library.

I've researched similar issues in this forum, but haven't found a definitive solution. It's worth noting that the same process, with the same Processing sketch, works perfectly in Max/MSP. Has anyone successfully sent OSC data to Processing using netsend in Pure Data? I'd greatly appreciate any guidance, examples, or advice on configuring the sending part of my patch.

Here are some screenshots and files for reference.

Thank you for your help in advance!

@cfry I would use [netsend] and pdreceive. Start up your [netsend] then run a command like pdreceive >> text_file.txt in a terminal and it will dump everything you feed your [netsend] right into a text file for you. This also gives you access to all those command line utilities which are designed for processing this sort of data and can upload it to the cloud/whatever as well all in one easy step.

@patricio.tics See "Networking" in https://danieliglesia.com/mobmuplat/doc/index.htm
Find the port inScore will use to receive..... and send to that port on the IP address of the machine running inScore...... or use a broadcast address if that IP might change on your network.
It is better practice to fix the IP of the receiving machine (static IP within the reserved range of your router........ instead of DHCP)
A bit more info about broadcast and multicast...... https://forum.pdpatchrepo.info/topic/14396/how-to-send-audio-over-the-network-in-pure-data/3
That info was for an audio object but the networking part is relevant for [netsend]
David.