On Mit, 2017-02-22 at 15:16 +0100, Christof Ressi wrote: > > > > maybe it's better to use [OSC] for the latter and [netsend] for > > single > > floats (f.e. to send a time-synch message) ? > 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, that's not a workable solution, even if it might seem to work for you. Since TCP is a stream oriented protocol and doesn't have any notion of packets, you need to implement some mechanism to delimit packets. OSC 1.0 proposed a 4-byte header to be prepended to each OSC packet that reflects the packet size. However, once the reading side gets it wrong, it will never able to the find the correct start of a packet again. That's why OSC 1.1 proposed SLIP encoding for serial / stream-oriented transports. > 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!). Absolutely no WTF. See above. > 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. I don't see a reason for OSC when both sides are Pd. FUDI isn't as common as OSC, though. Roman
signature.asc
Description: This is a digitally signed message part
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
