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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
