[PD] netsend/netreceive questions ...

[Roman Haefeli]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20170222/f92ad193/attachment.sig>