[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:
>>>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
>
>
> 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?
Martin
More information about the Pd-list
mailing list