Forums > MaxMSP

OSC communication

October 21, 2008 | 2:05 pm

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

Any recommendations on this?


October 21, 2008 | 3:01 pm

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.

– N.


October 22, 2008 | 6:45 am

Mhm, I was aware of that.
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.

Anyone else got any ideas about this?


October 22, 2008 | 1:59 pm

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.

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.


October 23, 2008 | 3:20 pm

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…

Cheers
j5


October 23, 2008 | 5:55 pm

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.


October 23, 2008 | 11:58 pm

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

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

http://cnmat.berkeley.edu/downloads

mz


October 24, 2008 | 6:48 am

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.


Viewing 8 posts - 1 through 8 (of 8 total)