On 2017-02-22 15:16, Christof Ressi wrote:
OSC is just a way to format your data and is independend from the actual protocol you use for transmitting the data. Most of the time you'll find OSC over UDP (e.g. [packOSC] -> [netsend -u -b] etc.) but it can also be TCP ([packOSC] -> [netsend -b])
no, this is broken by design.
or SLIP for sending over a serial connection ([packOSC] -> [mrpeach/slipenc] -> [comport]). I've once worked with an Ion lighting console which expected SLIP encoded OSC over TCP (wtf!).
SLIP-encoding is the only proper way to transmit OSC over TCP. TCP/IP is a stream-based protocol (like the serial-line used by [comport]), whereas OSC is a packet-based protocol. to transmit packets over a data stream, you must somehow packetize it; SLIP is the suggested format for doing that.
OSC itself just provides some convenience, it can be more efficient or not, depending on the message type. If you're just sending a single number, then FUDI* might make more sense. The difference might be neglectible, though.
FUDI takes 1 to 9 bytes to transmit a single float, OSC always takes exactly 4 bytes.
OSC transmits the float with full precision, whereas FUDI will truncate and whatnot.
For sending big lists of filenames I'd definitely go for TCP. Unfortunately, not all programs can handle OSC over TCP...
UDP-packets are limited in size (maximum 65536 bytes). so if you are sending large amounts of data, make sure that a single message doesn't exceed this size. (e.g. use multiple messages)
speaking of filenames: if you want to transmit strings/symbols with spaces (filenames on w32), OSC is certainly the better protocol (FUDI will split on the space).
IIRC the iemnet objects are threaded (also true for the mrpeach net objects?)
both are threaded. but iemnet uses a single worker thread to send the data, whereas mrpeach/net spins up a separate thread for each message.
afaict, this makes iemnet perform much better when dealing with large amounts of data. e.g. you can use it to saturate a 100MBit connection without audio dropouts (that is: without dropouts from the transmission itself; doing anything with that data will most likely clog your CPU). at least IIRC (i'm pretty sure about being able to saturate the connection; less sure about now audio dropouts)
mrpeach/net should block less than the built-in object, but in theory it might still block when spinning up to many threads. also mrpeach/net is prone to race-conditions, where one sending thread can overtake another sending thread (so the order of data arrival is not guaranteed). obviously mrpeach/net doesn't always exihibit that problem (else nobody would use it), but iirc i was able to trigger that behaviour in a lab situtation.
fgsdr IOhannes