how to specify the IP address and send a message to Processing

Hi, guys!

I'm using Arduino Yun and I want to send message to Processing
through wifi using by osc library made by CNMAT.

#include <OSCMessage.h>

Make an OSC message and send it over serial

#include <SLIPEncodedUSBSerial.h>
SLIPEncodedUSBSerial SLIPSerial( thisBoardsSerialUSB );
#include <SLIPEncodedSerial.h>
 SLIPEncodedSerial SLIPSerial(Serial1);

void setup() {
  //begin SLIPSerial just like Serial
  SLIPSerial.begin(9600);   // set this as high as you can reliably run on your platform
#if ARDUINO >= 100
    ; //Leonardo "feature"

void loop(){
  //the message wants an OSC address as first argument
  OSCMessage msg("/analog/0");

    msg.send(SLIPSerial); // send the bytes to the SLIP stream
  SLIPSerial.endPacket(); // mark the end of the OSC Packet
  msg.empty(); // free space occupied by message


I want to send a message to Processing using by this sample as a guide , but I do not know how to specify the IP address .How do you send a message by specifying the IP address of the Processing side ?

help me!

I have no experience with that library, but from a quick look at the page link you provided, and the code you posted, it is a protocol that works over the serial port, not the network - there is no IP address involved. In the code you posted, "/analog/0" is the OSC address.

The library seems hard-coded to use the various types of Serial ports. If it was written generically to use Stream objects (from which the Serial objects derive) then you could conceivably get it to work over a network by creating a YunClient object, connecting that to the remote computer using that computer's IP address) and then passing the YunClient object to the OSC library. But it looks like it would require quite some modifications to support that, even though both the YunClient and the hardware serial objects derive from the same Stream class.

But then that's only half the battle: you would have to modify the Processing code on the other end to create a TCP socket server to listen for the incoming connection, and talk over that network port rather than the serial port.

It seems to me that getting this protocol to work over the network is not going to be trivial.