derp mcderpington

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.

p.s. totally posted this in the wrong forum.

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

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

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.

udpreceive confusion