Hans-Christoph Steiner wrote:
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?
Maybe [OSCpack] would take an OSC path in its left inlet and whatever types were specified by its arguments in the other inlets, the same as [pack], so something like: [/my/item 11( | [OSCpack i] | [netsend] ...would send 11 as an int, but [OSCpack s] would send it as a string and [OSCpack f] a float.
[OSCunpack] could have one outlet for a list comprising the path separated into symbols followed by the data. This could go to [route] for further processing. [netreceive] | [OSCunpack] | [route my] | [route item] | [11\
or alternatively it could be more like [unpack] and have an outlet for
each datum:
[netreceive]
|
[OSCunpack /my/item i]
|
[11
...but that would only unpack one specific OSC address, so you would
need one for each OSC endpoint.
Ideas?
Martin