[PD] Very Strange Behaviour of dumpOSC on Pd

Roman Haefeli reduzierer at yahoo.de
Thu Feb 5 17:35:02 CET 2009

--- Jack <jack at rybn.org> schrieb am Do, 5.2.2009:

> Yep, as Roman says try [udpreceive] with [unpackOSC] (OSC
> comme often  
> 'on' UDP) or [tcpreceive] with [unpackOSC], if you
> want a service  
> with connection. The choice depends if you absolutely need
> to receive  
> your data.
> AFAIK, OSCx accepts only UDP protocol.

you cannot use [tcpsend]/[tcpreceive] use together with [packOSC]/[unpackOSC], since there is a special OSC specification for stream oriented transport layers such as TCP. OSC assumes that either the transport layer takes care of the corrent handling of packets (which is the case for udp) and specifies a special header for OSC packets, when it is transported over a stream oriented protocol (TCP). 

this makes the use of OSC over TCP much more complex. i made some abstractions for mrpeach to handle this correctly. here a little description about using them as intended:


- for unidirectional TCP connections, use:
   [packOSCstream] and [tcpsend] for the sender side and
   [tcpreceive] and [unpackOSCstream] on the receiver side

- for bidirectional TCP connections, use:
   -on the server side:
    [tcpsocketserver OSC <port>] with [unpackOSC] for receiving and
    [packOSCstream] for sending
   -on the client side:
    [tcpclient] with [unpackOSCstream] for receiving and [packOSCstream]
    for sending

(for the sake of completeness:)


  - for sending: [packOSC] with [udpsend]
  - for receiving: [unpackOSC] with [udpreceive]

i know, this sounds all complicated. actually i made those abstractions to get at least raw functionality, so that transporting OSC over TCP is possible at all. in order to make things less confusing and more obvious, i guess, i should add more high level abstractions, that contain the networking and un/packing stuff in once class.



More information about the Pd-list mailing list