On Mar 22, 2006, at 11:09 AM, Martin Peach wrote:
Hans-Christoph Steiner wrote:
On Mar 21, 2006, at 7:23 PM, Martin Peach wrote:
day 5 wrote:
On Mar 16, 2006, at 12:43 PM, B. Bogart wrote:
In fact I think the whole OSC external thing needs to be
rethought.why not just implement a wrapper to liblo ?
Investigating further, I see that liblo can only send via UDP
and UNIX sockets, not TCP. It handles its own sockets internally
just like libOSC (the basis for sendOSC and dumpOSC in pd). In pd, netsend and netreceive can do TCP as well. OSC is
supposed to work on 'any' protocol, but AFAIK it hasn't been
implemented on MIDI or RS232 or USB, probably for lack of
interest. At least a TCP implementation would be useful for
those who need guaranteed delivery of packets.CCRMA at Stanford University has a limited version of OSC on
serial called dumpOSCSerial. I never found the code, just hte
binary. Ideally, there would be a Pd OSC lib that had no
transport built in. Then you could choose your transport. That
makes things much more flexible..hc
I agree. If there were objects called [OSCpack] and [OSCunpack]
that worked analogously to [pack] and [unpack] they would output
and input data in OSC binary format, I suppose as a list of floats
in pd-land.
Sounds like its going down the right track. How it would work
exactly? OSC has two parts:
/my/item 11
Would these un/pack objects just handle the first part?
.hc
Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli