[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