udpreceive confusion
Maybe I'm misunderstanding how udpreceive is supposed to work- but it currently restricts incoming packets to those which are formatted in osc 4 byte string-padded messages. I do not want this to (necessarily) be the case.
mxj net.udp.recv doesn't require osc-formatted incoming messages, so that's a workaround for now, but I'm not in love with java externals.
I thought the OSC-full-packet-designation argument would allow me to receive raw udp messages with the udpreceive object, but this wasnt working... - after re-reading what this argument does, i believe it may be something else entirely.
can i get some clarification? if this is how it's intended to function, let me add as a feature request a message-based switch that allows the full message to pass through without giving me those nasty error messages about incorrectly formatted strings and such- should be easy enough.
Thanks!
Brian
p.s. totally posted this in the wrong forum.
[udpreceive] is built to be compatible with OSC packets, therefore it will confirm to OSC restrictions.
There's really no reason to not use the [net.udp.recv] object - it functions perfectly for what you've described, and you won't see a performance difference if you're using a fairly new computer. If you want more control over buffering you can write your own Java object - the java.net API is quite good.
I'm not a full-on java hater, it has its uses and I've written in it plenty, but I have my own project-specific nitpicky reasons for why it'd be useful to have this in C in this particular instance. I guess what I'm sayin is, a "relax restrictions" command for udpreceive wouldn't be the worst thing in the world. I've written streamers for C++ and java, and between the two of 'em, you're right, it's easier in java.