[PD] osc objects

Hans-Christoph Steiner hans at eds.org
Thu Apr 27 16:36:50 CEST 2006


On Apr 27, 2006, at 2:03 AM, B. Bogart wrote:

> I think OSCx should be deprecated,
>
> left around only for compatibility with old patches.
>
> Seems to me Martin's OSC stuff does the same and more than the orginal
> OSCx, so keeping them both around makes little sense.
>
> Especially when it means giving the (hopefully more used) routeOSC a
> name like set_route.
>
> Actually I think we could do:
>
> net/tcpsend
> net/tcpreceive
> net/udpsend
> net/udpreceive

sound ok to me.

> osc/route
> osc/pack
> osc/unpack

I think these should be more descriptive.  They don't work exactly  
the same as the core versions, so they should have different, but  
similar, names.

The suffix is fine, but it should be consistent across objects in the  
lib, like:

[osc/packOSC]
[osc/unpackOSC]
[osc/routeOSC]

.hc


>
> ..b.
>
>
> Hans-Christoph Steiner wrote:
>>
>> On Apr 26, 2006, at 11:01 PM, Piotr Majdak wrote:
>>
>>> Hi Martin,
>>>
>>> Martin Peach wrote:
>>>
>>>> Sure...[routeOSC] is based on [OSCroute] but the routes are   
>>>> settable
>>>> after the object is created. It is also standalone in the  sense  
>>>> that
>>>> you don't need to load lib OSC to use it. It's  basically the same
>>>> code, cleaned up a bit.
>>>> [unpackOSC] is based on [dumpOSC], again nearly the same thing but
>>>> cleaned up and made independent of lib OSC.
>>>> For instance the messages to the user use 'post' instead of printf
>>>> and OSCerror or whatever it was.
>>>> [packOSC] is based on [sendOSC] but doesn't do the network part.
>>>> That can be handled by [udpsend] or [tcpsend] or possibly   
>>>> [comport]
>>>> and [midiout] with some extra massaging of the lists  they output.
>>>> That makes the OSC objects transport independent as  the spec
>>>> intended (but nearly every implementation is hard-wired  to use  
>>>> udp).
>>>
>>>
>>> That's a nice thing. So, as far as I understand you, [packOSC]
>>> outputs something (a stream of messages, one message per byte?)   
>>> which
>>> can be sent to a communication object such as [udpsend] or   
>>> [comport]?
>>>
>>> But, the oposite object to [packOSC], [unpackOSC] is hardcoded to
>>> UDP, like [sendOSC], right?
>>
>>
>> These are really great, it should make things much more flexible.
>>
>>>> I used different names for all of them so as not to break existing
>>>> patches.
>>>
>>>
>>> That's a good idea. Thanks for watching the weird compatibility
>>> things :-)
>>>
>>>> I based them all on OSCx (the net objects are based on the   
>>>> [netsend]
>>>> and [netreceive] objects inside pd), I consider them to  be an
>>>> improved version of OSCx but that's my opinion :)
>>>
>>>
>>> I see it as an improvement too :-) Would you like to add your   
>>> objects
>>> to the externals/OSCx directory in CVS? We could keep all  the OSC
>>> stuff at one place...
>>
>>
>> I think it might make more sense to make a separate library for these
>> objects.  But if they are based on libOSC, then they could be
>> integrated.  [OSCroute] and [routeOSC] in the same package sounds  
>> a  bit
>> odd to me.  Perhaps [routeOSC] could be renamed to soemthing like
>> [set_route].
>>
>> .hc
>>
>> _____________________________________________________________________ 
>> ___
>> ____
>>
>> "I have the audacity to believe that peoples everywhere can have   
>> three
>> meals a day for their bodies, education and culture for their  minds,
>> and dignity, equality and freedom for their spirits."
>>                                             - Martin Luther King, Jr.
>>
>>
>> _______________________________________________
>> PD-list at iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list


________________________________________________________________________ 
____

"Looking at things from a more basic level, you can come up with a  
more direct solution... It may sound small in theory, but it in  
practice, it can change entire economies."
                                                     - Amy Smith





More information about the Pd-list mailing list