OSC communication

Oct 21, 2008 at 2:05pm

OSC communication

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?

#40449
Oct 21, 2008 at 3:01pm

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.

#143154
Oct 22, 2008 at 6:45am

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?

#143155
Oct 22, 2008 at 1:59pm

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.

#143156
Oct 23, 2008 at 3:20pm

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

#143157
Oct 23, 2008 at 5:55pm

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.

#143158
Oct 23, 2008 at 11:58pm

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

#143159
Oct 24, 2008 at 6:48am

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.

#143160

You must be logged in to reply to this topic.