[PD] Re: [PD-dev] We've got to undo the MIDI revolution! - Where isOSC?!

[Martin Peach]

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