[PD] Very Strange Behaviour of dumpOSC on Pd

[Jack]

Thanx Roman for the clarification. I thought that [tcpsend]/ 
[tcpreceive] worked with OSC.
I think it must be specify somewhere in the help patch (with  
[packOSC]/[unpackOSC] or/and [tcpsend]/[tcpreceive] ?).
I just download abstractions from :
http://romanhaefeli.net/software/pd/OSCstream.tar.gz
I will see that tomorrow.
++

Jack


Le 5 févr. 09 à 17:35, Roman Haefeli a écrit :

>
>
>
> --- 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:
>
> OSC OVER TCP
>
> - 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:)
>
> OSC OVER UDP
>
>   - 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.
>
> roman
>
>
>