HSel

Im sending OSC messages to Max from java.

To send the messages Im using javaosc (found here: 

http://www.illposed.com/software/javaosc.html).

And on the Max side Im using [udpreceive].

The problems comes when sending a String containing non-western characters. It seems to go out from the java app ok, with the correct character encoding, but [udpreceive] seems to misinterpret non-western characters. Maybe [udpreceive]'s OSC is UTF-8 only?

Would it work using [udpreceive CNMAT] and then decoding the FullPacket message with a different object? (it appears that CNMAT's [OpenSoundControl] object is unsupported now though).

Hi all,
Im sending OSC messages to Max from java.
To send the messages Im using javaosc (found here: http://www.illposed.com/software/javaosc.html).
And on the Max side Im using [udpreceive].

This works well in most cases.
The problems comes when sending a String containing non-western characters. It seems to go out from the java app ok, with the correct character encoding, but [udpreceive] seems to misinterpret non-western characters. Maybe [udpreceive]'s OSC is UTF-8 only?

Would it work using [udpreceive  CNMAT] and then decoding the FullPacket message with a different object? (it appears that CNMAT's [OpenSoundControl] object is unsupported now though).

osc-communication

On Tue, Oct 21, 2008 at 08:05:58AM -0600, Hans wrote:

> The problems comes when sending a String containing non-western characters. It seems to go out from the java app ok, with the correct character encoding, but [udpreceive] seems to misinterpret non-western characters. Maybe [udpreceive]'s OSC is UTF-8 only?

OSC is byte-oriented, and I don't think there's any kind of spec. for

character encoding. Depending how you convert your Java strings to

bytes, you could end up with an arbitrary encoding which may or may

On Tue, Oct 21, 2008 at 08:05:58AM -0600, Hans wrote:
> The problems comes when sending a String containing non-western characters. It seems to go out from the java app ok, with the correct character encoding, but [udpreceive] seems to misinterpret non-western characters. Maybe [udpreceive]'s OSC is UTF-8 only?

OSC is byte-oriented, and I don't think there's any kind of spec. for
character encoding. Depending how you convert your Java strings to
bytes, you could end up with an arbitrary encoding which may or may
not be understood by the receiver.

Which is why I think my problem could be at two possible positions.

1. When the OSCPacket is encoded on the Java part. This is handled by the OSC library Im using, so I have no direct control over the encoding myself.

2. When Max's [updreceive] decodes the incoming message. If the decoder doesn't handle non-western characters, then I suppose the result would be the same.

Im currently trying to investigate both possibilities.

Another thing I could do, which might actually be the best way either way, is to send udp packets directly, and not use OSC.

I just chose OSC because of its easy of use.

Mhm, I was aware of that.
Which is why I think my problem could be at two possible positions.

Im currently trying to investigate both possibilities.
Another thing I could do, which might actually be the best way either way, is to send udp packets directly, and not use OSC.
I just chose OSC because of its easy of use.

For those interested, I found a fix for this.

 to encode OSC messages now, and then send them using java.nio.channels.DatagramChannel.

On the Max I then receive using [udpreceive ].

This seems to keep all characters constant on both sending and receiving side, guessing it'll work for all unicode characters.

For those interested, I found a fix for this.
I use NetUtil(http://www.sciss.de/netutil/) to encode OSC messages now, and then send them using java.nio.channels.DatagramChannel.

This seems to keep all characters constant on both sending and receiving side, guessing it'll work for all unicode characters.


Quote: HSel wrote on Tue, 21 October 2008 08:05

----------------------------------------------------

> Would it work using [udpreceive CNMAT] and then decoding the FullPacket message with a different object? (it appears that CNMAT's [OpenSoundControl] object is unsupported now though).

Where'd you hear/find that? [OpenSoundControl] seems to work fine for me in max 5.0.5, and the CNMAT page says I don't even have the latest version (ie the version on the CNMAT server was uploaded on October 6th).

If this is some sort of Official word form somewhere I would love to hear more about it...

Quote: HSel wrote on Tue, 21 October 2008 08:05
----------------------------------------------------

> Would it work using [udpreceive  CNMAT] and then decoding the FullPacket message with a different object? (it appears that CNMAT's [OpenSoundControl] object is unsupported now though).
----------------------------------------------------

Where'd you hear/find that? [OpenSoundControl] seems to work fine for me in max 5.0.5, and the CNMAT page says I don't even have the latest version (ie the version on the CNMAT server was uploaded on October 6th). 

Just found out that [OpenSoundControl] works just fine in max5.

I had just been checking out [otudp] and found this site:

http://cnmat.berkeley.edu/OpenSoundControl/Max/

And thought that because Cycling had brought it natively into Max that they'd stopped supporting. 

It appears I was wrong... sorry for the confusion.

Ooops, sorry about that.
Just found out that [OpenSoundControl] works just fine in max5.
I had just been checking out [otudp] and found this site:
http://cnmat.berkeley.edu/OpenSoundControl/Max/
And thought that because Cycling had brought it natively into Max that they'd stopped supporting. 
It appears I was wrong... sorry for the confusion.


I'm not sure if this will solve your problem, but OpenSoundControl is certainly supported.

>
> Would it work using [udpreceive  CNMAT] and then decoding the FullPacket message with a different object? (it appears that CNMAT's [OpenSoundControl] object is unsupported now though).
>

Found a solution though, posted a couple of posts further up.

The error was with the way I sent the messages, not in how they were received.

Yeah, I tried that. Same result.
Found a solution though, posted a couple of posts further up.
The error was with the way I sent the messages, not in how they were received.


OSC communication