Savage Henry

This is my first post on here, I've tried searching for a solution to my problem to no avail... Hopefully I'm not the only one who has come across this!

My patch is a very simple test of communication between java and max- I'm using the following code in my bang() method (in mxj):

TcpSender test = new TcpSender("localhost", 3000);

Atom a[] = new Atom[]{Atom.newAtom("Hello!"), Atom.newAtom(";")};

Now, in my patch there is only a netreceive object set to port 3000. When I send a bang into my mxj object I get the following in the Max window:

I thought I'd cracked the problem by adding the ";" into the Atom in the code above, as previously the message wasn't coming through - I only got the EOF error... so, now I have the message and the error and I'm confused.

It's not a problem for this particular patch, but I'm testing for a patch that uses 100 or so netreceives at a time and the errors are crashing my mac!

Is it possible that it's a problem with the netreceive object itself? Or is there a far simpler way of doing this? Or am I missing something f-ing obvious?!

Thanks a lot, any help is much appreciated!

TcpSender test = new TcpSender("localhost", 3000);
Atom a[] = new Atom[]{Atom.newAtom("Hello!"), Atom.newAtom(";")};
tic.send(a);
tic.close();

print: Hello!
netreceive: EOF on socket 132

netreceive-eof-on-socket

The EOF is indicating that the TCP connection has closed. Likely what 

you want to do is create a TcpSender when your mxj object is created, 

and close it when your object is deleted, and just create and send 

If you don't need that kind of connection to persist throughout the 

life of your object, you could also consider using UDP which is a 

> This is my first post on here, I've tried searching for a solution 

> to my problem to no avail... Hopefully I'm not the only one who has 

> My patch is a very simple test of communication between java and 

> max- I'm using the following code in my bang() method (in mxj):

> TcpSender test = new TcpSender("localhost", 3000);

> Atom a[] = new Atom[]{Atom.newAtom("Hello!"), Atom.newAtom(";")};

> Now, in my patch there is only a netreceive object set to port 

> 3000. When I send a bang into my mxj object I get the following in 

> I thought I'd cracked the problem by adding the ";" into the Atom 

> in the code above, as previously the message wasn't coming through 

> - I only got the EOF error... so, now I have the message and the 

> It's not a problem for this particular patch, but I'm testing for a 

> patch that uses 100 or so netreceives at a time and the errors are 

> Is it possible that it's a problem with the netreceive object 

> itself? Or is there a far simpler way of doing this? Or am I 

> Thanks a lot, any help is much appreciated!

The EOF is indicating that the TCP connection has closed. Likely what  
you want to do is create a TcpSender when your mxj object is created,  
and close it when your object is deleted, and just create and send  
atoms in your bang message handler.

If you don't need that kind of connection to persist throughout the  
life of your object, you could also consider using UDP which is a  
connectionless protocol.

On 07-05-31, at 1312, Sam Salem wrote:
>
> Hello everyone,
>
> This is my first post on here, I've tried searching for a solution  
> to my problem to no avail... Hopefully I'm not the only one who has  
> come across this!
>
> My patch is a very simple test of communication between java and  
> max- I'm using the following code in my bang() method (in mxj):
>
> TcpSender test = new TcpSender("localhost", 3000);
> Atom a[] = new Atom[]{Atom.newAtom("Hello!"), Atom.newAtom(";")};
> tic.send(a);
> tic.close();
>
> Now, in my patch there is only a netreceive object set to port  
> 3000. When I send a bang into my mxj object I get the following in  
> the Max window:
>
> print: Hello!
> netreceive: EOF on socket 132
>
> I thought I'd cracked the problem by adding the ";" into the Atom  
> in the code above, as previously the message wasn't coming through  
> - I only got the EOF error... so, now I have the message and the  
> error and I'm confused.
>
> It's not a problem for this particular patch, but I'm testing for a  
> patch that uses 100 or so netreceives at a time and the errors are  
> crashing my mac!
>
> Is it possible that it's a problem with the netreceive object  
> itself? Or is there a far simpler way of doing this? Or am I  
> missing something f-ing obvious?!
>
> Thanks a lot, any help is much appreciated!
>
> -s.


Thanks for the speedy response! I think you may be right, however I'm still getting the same EOF message when I place the TcpSender constructor within the constructor of my class, or even when it's placed at the beginning of my class and declared public (I've also removed the .close() method).

I've tried replacing the TcpSender constructor with the UdpSender constructor and nothing at all happens when I bang my mxj object (I've added the second "1" argument to my netreceive object). If Udp is connectionless it may serve my purpose better as it sounds like it will require less maintenance, but at the moment it's not doing a great deal.

> Thanks for the speedy response! I think you may be right, however 

> I'm still getting the same EOF message when I place the TcpSender 

> constructor within the constructor of my class, or even when it's 

> placed at the beginning of my class and declared public (I've also 

Its been a while since I've looked at networking or java, but I think 

what you need to do is have a TcpSender as a private member variable 

of your mxj class, and create it in your constructor.

> I've tried replacing the TcpSender constructor with the UdpSender 

> constructor and nothing at all happens when I bang my mxj object 

> (I've added the second "1" argument to my netreceive object). If 

> Udp is connectionless it may serve my purpose better as it sounds 

> like it will require less maintenance, but at the moment it's not 

You will need to use a UDP receiver with the UDP sender.

Do the net.tcp.send/recv and net.udp.send/recv pairs not work for 

your application? I don't know what your netreceive object is.

You might also want to try reading Beej's guide to network 

programming if you have time, it will give you a better understanding 

(maybe) of what's going on here. Its targetted at C programmers, but 

you might be able to pick enough out of it to get going with java.

On 07-05-31, at 1350, Sam Salem wrote:
>
> Hello there,
>
> Thanks for the speedy response! I think you may be right, however  
> I'm still getting the same EOF message when I place the TcpSender  
> constructor within the constructor of my class, or even when it's  
> placed at the beginning of my class and declared public (I've also  
> removed the .close() method).
>
Its been a while since I've looked at networking or java, but I think  
what you need to do is have a TcpSender as a private member variable  
of your mxj class, and create it in your constructor.

> I've tried replacing the TcpSender constructor with the UdpSender  
> constructor and nothing at all happens when I bang my mxj object  
> (I've added the second "1" argument to my netreceive object). If  
> Udp is connectionless it may serve my purpose better as it sounds  
> like it will require less maintenance, but at the moment it's not  
> doing a great deal.
>
You will need to use a UDP receiver with the UDP sender.

Do the net.tcp.send/recv and net.udp.send/recv pairs not work for  
your application? I don't know what your netreceive object is.

You might also want to try reading Beej's guide to network  
programming if you have time, it will give you a better understanding  
(maybe) of what's going on here. Its targetted at C programmers, but  
you might be able to pick enough out of it to get going with java.
http://beej.us/guide/bgnet/

Thanks for the help and advice - I am new to the networking and have a bit of perceptual block when it comes to Java!

The reason why I'm not using net.tcp.send et al is that I'm trying to use TCP/UDP to communicate between the Java program and a set of Jitter abstractions. The abstractions are dynamically created/killed by the Java program, which updates each abstraction during its lifetime (or at least hopefully will at some point).

Netreceive is a max external for networking written by Olaf Matthes- it's available from: 

Thanks for the help and advice - I am new to the networking and have a bit of perceptual block when it comes to Java! 

Netreceive is a max external for networking written by Olaf Matthes- it's available from: http://www.akustische-kunst.org/maxmsp/ 

Max also has objects for UDP that are used to communicate with the 

On May 31, 2007, at 14:20 PM, Sam Salem wrote:

> Thanks for the help and advice - I am new to the networking and 

> have a bit of perceptual block when it comes to Java!

> The reason why I'm not using net.tcp.send et al is that I'm trying 

> to use TCP/UDP to communicate between the Java program and a set of 

> Jitter abstractions. The abstractions are dynamically created/ 

> killed by the Java program, which updates each abstraction during 

> its lifetime (or at least hopefully will at some point).

> Netreceive is a max external for networking written by Olaf 

Max also has  objects for UDP that are used to communicate with the  
lemur.
udpsend and udpreceive I believe.
t

>
> Thanks for the help and advice - I am new to the networking and  
> have a bit of perceptual block when it comes to Java!
>
> The reason why I'm not using net.tcp.send et al is that I'm trying  
> to use TCP/UDP to communicate between the Java program and a set of  
> Jitter abstractions. The abstractions are dynamically created/ 
> killed by the Java program, which updates each abstraction during  
> its lifetime (or at least hopefully will at some point).
>
> Netreceive is a max external for networking written by Olaf  
> Matthes- it's available from: http://www.akustische-kunst.org/maxmsp/
>
> Anyway, thanks a lot!
>
> s.


Ah, thanks a lot for that! The UdpSender() worked instantly with the udpreceive object - problem is it doesn't understand the message being sent, so time to look up a Java implementation of OSC...

So, I've looked at the com.illposed.osc Java implementation of OSC and needless to say, I can't even get the example to compile - we end up with a lot of compilation errors pointing to UnknownHostExceptions - to be honest I had hoped to not have to deal with java.net.*;!

My patch consists of a udpreceive connected to an opensoundcontrol object connected to a print. My bang() method is still:

Atom a[] = new Atom[]{Atom.netAtom("I am tired"), Atom.newAtom("Please work!")};

net.recv.udp: OSC packet size (19) not a multiple of 4 bytes: dropping

As far as I can tell, it seems that the message being sent needs to be converted to the OSC message format, so I tried using the following method from the Java OSC implementation:

OSCJavaToByteArrayConverter Henry = new OSCJavaToByteArrayConverter();

//then to convert Henry's protected byte stream to a byte array

104 97 104 97 104 97 0 0 112 108 101 97 115 101 32 119 111 114 107 33 0 0 0 0 0 0 0 0 

net.recv.udp: OSC packet size (85) not a multiple of 4 bytes: dropping

Any ideas?! I think it may be the conversion from byte[] to atom[], altho it could also be the conversion from byte stream to byte[] as I have no reason to believe that the java osc implementation works.

UdpSender test = new UdpSender();
test.setAddress("localhost");
test.setPort(5000);

String s = Atom.toOneString(a);
post(a);
test.send(a);

I am tired Please work!
net.recv.udp: OSC packet size (19) not a multiple of 4 bytes: dropping

OSCJavaToByteArrayConverter Henry = new OSCJavaToByteArrayConverter();
Henry.write("I am very tired");
Henry.write("Please work!");
Henry.appendNullCharToAlignStream();

//then to convert Henry's protected byte stream to a byte array
byte[] tester = Harry.toByteArray();

Atom a[] = Atom.newAtom(tester);
test.send(a);

104 97 104 97 104 97 0 0 112 108 101 97 115 101 32 119 111 114 107 33 0 0 0 0 0 0 0 0 
net.recv.udp: OSC packet size (85) not a multiple of 4 bytes: dropping

Any ideas?! I think it may be the conversion from byte[] to atom[], altho it could also be the conversion from byte stream to byte[] as I have no reason to believe that the java osc implementation works. 

Ok, I switched over to the de.sciss.net library and it seemed to work fairly instantly (

 - it's a little more low level than I would've liked, but I'm not complaining :)

Ok, I switched over to the de.sciss.net library and it seemed to work fairly instantly (http://www.sciss.de/netutil/) - it's a little more low level than I would've liked, but I'm not complaining :)


I don't under stand why tour bang method wouldn't outlet a max message 

which could be sent to udpsend.I also don't understand the need for an 

osc object.udpsend and receive understand a large subset of osc but it 

just seems like you are sending around max messages.maybe I am not 

I don't under stand why tour bang method wouldn't outlet a max message 
which could be sent to udpsend.I also don't understand the need for an 
osc object.udpsend and receive understand a large subset of osc but it 
just seems like you are sending around max messages.maybe I am not 
understanding something.


Netreceive: EOF on socket #...