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

Hans-Christoph Steiner hans at eds.org
Thu Mar 23 07:12:36 CET 2006


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





More information about the Pd-list mailing list