[PD] osc objects

[Hans-Christoph Steiner]

On Apr 28, 2006, at 7:59 PM, Martin Peach wrote:

> Mathieu Bouchard wrote:
>> On Wed, 26 Apr 2006, B. Bogart wrote:
>>> Actually I think we could do:
>>> net/tcpsend
>>> net/tcpreceive
>>> net/udpsend
>>> net/udpreceive
>> bidi connections are nice, so let's merge the send/receive parts  
>> together:
>> net/tcpsocket
>> net/udpsocket
>
> But we don't have midisocket, just midiin and midiout, and it's  
> easier to patch that way.
> For instance I'm using OSC to talk to microcontrollers on one port  
> but they reply on another. To me it makes more sense to have  
> separate send and receive objects
>
>> and each would be both able to run in server mode (waiting for  
>> connections) and client mode (issuing connections), and if not,  
>> call the server mode objects like:
>> net/tcpserver
>> net/udpserver
>
> tcpreceive accepts multiple incoming connections (maximum is set by  
> a #define in the code but it could be a creation argument if  
> needed), and updreceive accepts any messages sent to its port  
> number. Both also output the ip address of the source of each  
> incoming message.

I have to say that I really think that tcp and udp objects should be  
bidirectional.  TCP and UDP sockets are, so the objects should  
represent that.  I've done quite a bit of network programming with Pd  
and I never use [netsend]/[netreceive].  I always use [netserver]/ 
[netclient] because of the bidirectional connection and the client  
management of the [netserver].

I think the "server" aspect could be a separate object.  I think the  
socket objects should represent just the sockets, and how the sockets  
work.

.hc

________________________________________________________________________ 
____

"Information wants to be free."
                                      -Stewart Brand