[PD] osc objects

Martin Peach martinrp at vax2.concordia.ca
Mon May 1 23:16:02 CEST 2006

Mathieu Bouchard wrote:
> On Fri, 28 Apr 2006, Martin Peach wrote:
>>Mathieu Bouchard wrote:
>>>bidi connections are nice, so let's merge the send/receive parts together:
>>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
> You gotta be kidding. A lot of protocols that Pd could support require a
> bidirectional connection. That is, you can't find a version of the
> protocol that works by first establishing a socket one way and then
> connecting back the other way. It wouldn't work in masquerading IP
> situations either.

Oh I see...I was thinking you could just make an abstraction with 
tcpsend and tcpreceive in the same patch and it would work just like a 
bidirectional socket, but I probably didn't think far enough...I'm no 
good at chess either...

In my own selfish way I am using [udpsend] and [udpreceive] in a single 
patch as separate objects. I have pd sending messages to several micros 
on a subnet, with one [udpsend] for each connection; the micros can then 
reply to a single [udpreceive] on the same or a different port number. 
The protocol is just OSC over udp and it works fine for me. I use an OSC 
message like: /replyto/ 9999 so I can tell each micro to talk back on an 
arbitrary port. So as I said, to me it makes more sense to have separate 
objects. For other applications it doesn't. I'll work on [netclient] and 
[netserver] for those, when I can.

> DesireData is going to have those byte-based sockets for sure. The
> client-server protocol of Pd itself is bidi, and I believe a user ought to
> be able to do the same! This means that i want one class for both send and
> receive.
>>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.
> But receive is reserved for servers, and servers are reserved for 
> receiving, while sending is reserved for clients, and clients can only 
> send. Why?

Why what?


More information about the Pd-list mailing list