problem with osc, udp, and the mxj net.* objects?
Hi all,
I am having difficulty receiving OSC messages from an iOS app using the mxj net objects.
When I use the udpreceive object, the OSC messages arrive intact, but when I use the mxj net.* objects, only the parameter address arrives, without the associated values.
The iOS app is sending > and the packet looks like
udpreceive prints "/parameter_name 1.5464353"
mxj net.* prints "/paramter_name" only.
Perhaps my iOS app is not formatting the OSC messages correctly for the mxj net objects, but udpreceive can handle it?
Is there any documentation on OSC formatting for mxj objects?
The mxj objects offer multicasting, which is the reason for not using the udpreceive object.
Any suggestions for getting OSC values using mxj net objects, or another work around for multicast udp receive in Max?
Right now, my workaround is to append the parameter_address with the value itself and then parsing the parameter_address in Max.
I'm using the vvosc library in the iOS app, in cast anyone is familiar with the way vvosc formats osc messages.
thanks in advance!
kristin
UPDATE: when I move the slider on the iOS device, I see this in the Max Window
printit: received MESSAGE "/slider
...as if the rest of the message doesn't exist - but when I run the output mxj net object through an "atoi" object, I can see the final 6 ints changing when i move the slider - the data is there, I just can't get to it through osc-route or route. The only way I can get to it is by running it through "atoi," filtering out some data in between the parameter_name and parameter value like 192, 128, an "f" and a comma, and some more 192s and 128s... then it goes back through an "itoa" object, making everything painfully slow.
My question is: Why does udpreceive deal with this extra info, while the mxj net objects do not? Which might clarify how I need to format my outgoing osc for the mxj net object...
thanks again!
k
I can reproduce this with data I'm sending from Processing to Max. I have problems with using mxj net.udp.recv but none when using udpreceive in either regular or compatibility mode.
It seems mxj is dropping the ball on messages with arguments:
Sorry I'm not more help.
thanks for the verification.
I looked at the sourcecode for mxj net.udp.recv
and it uses the MultiReceiver class from com.cycling74.net
"Connect to and receive from multicast groups. An internal Callback is maintained from a specified method name and object. The specified method must take an array of Atoms as its only argument. When data is received, it is translated to an array of Atoms and passed to the specified method."
maybe the osc messages aren't formatted as an array of Atoms that Mxj net.udp.recv can interpret.
But it seems like some, OSC parsing is already being done before the object outputs the partial message.
hmmm...
file://localhost/Applications/Max6/java-doc/api/com/cycling74/net/MultiReceiver.html
also one quotation mark shows up in the middle of the OSC message
The best solution I came up with was to edit the mxj net objects - removing unwanted characters from the atom array before it goes to max... and then stripping the incoming osc messages of spaces, because that is where the mxj net objects add the extra characters. Since message objects and the print object generally ignore these characters in addition to seemingly random quotation marks, I had to use the "Printit" object to actually see the problematic one-sided quotes... which was only an issue when converting strings into numbers.
the bug adds a lot of 192 and 128 ascii symbols inconsistently AND the net objects do not process osc indications for s, f, and i values.
filtering the strings of unwanted characters and removing the spaces on the osc seems to be working.
added something like this to get rid of the 192 and 128 asciis
private void receiver(Atom[] a) {
String[] atomsAsStrings = Atom.toString(a);
for( int i = 0; i
{
atomsAsStrings[i] = atomsAsStrings[i].replaceAll("[^a-zA-Z0-9-=+/!@#$%^&*]","");
}
outlet (0, atomsAsStrings);
}