[PD] osc objects

Piotr Majdak piotr at majdak.com
Wed Apr 26 23:01:05 CEST 2006


Hi Martin,

Martin Peach wrote:
> Sure...[routeOSC] is based on [OSCroute] but the routes are settable 
> after the object is created. It is also standalone in the sense that you 
> don't need to load lib OSC to use it. It's basically the same code, 
> cleaned up a bit.
> [unpackOSC] is based on [dumpOSC], again nearly the same thing but 
> cleaned up and made independent of lib OSC.
> For instance the messages to the user use 'post' instead of printf and 
> OSCerror or whatever it was.
> [packOSC] is based on [sendOSC] but doesn't do the network part. That 
> can be handled by [udpsend] or [tcpsend] or possibly [comport] and 
> [midiout] with some extra massaging of the lists they output. That makes 
> the OSC objects transport independent as the spec intended (but nearly 
> every implementation is hard-wired to use udp).

That's a nice thing. So, as far as I understand you, [packOSC] outputs 
something (a stream of messages, one message per byte?) which can be 
sent to a communication object such as [udpsend] or [comport]?

But, the oposite object to [packOSC], [unpackOSC] is hardcoded to UDP, 
like [sendOSC], right?

> I used different names for all of them so as not to break existing patches.

That's a good idea. Thanks for watching the weird compatibility things :-)

> I based them all on OSCx (the net objects are based on the [netsend] and 
> [netreceive] objects inside pd), I consider them to be an improved 
> version of OSCx but that's my opinion :)

I see it as an improvement too :-) Would you like to add your objects to 
the externals/OSCx directory in CVS? We could keep all the OSC stuff at 
one place...

br, Piotr





More information about the Pd-list mailing list