[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