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