[PD] osc objects

[Martin Peach]

dafydd hughes wrote:
> Hi guys
> 
> Martin - these objects look really cool.  I think they'll be incredibly useful.
> 

Great! Thanks.

> Now for the bit where I feel like a dunce...  I have no idea how to
> compile these things without a makefile.  (I'm on OSX but I'll be
> doing this on Linux too)  I've copied m_pd.h from the 0.39-2 source
> into the directory I'm working in.  Tried the following but I have no
> idea where to go from here.  I'm sure it's a simple solution but it
> escapes me.

I don't know about OSX but on linux I use this (single line) command:
gcc -Wall -O2 -DPD -shared -o route.pd_linux 
-I/home/martin/pd-0.39-2/src routeOSC.c -L/usr/local/lib

You need to say -shared so that ld doesn't try to find main and the 
other functions inside pd.

Martin

> 
> butterfly:~/cvs dafydd$ gcc routeOSC.c
> /usr/bin/ld: Undefined symbols:
> _main
> _class_addanything
> _class_addlist
> _class_addmethod
> _class_new
> _class_sethelpsymbol
> _gensym
> _outlet_anything
> _outlet_bang
> _outlet_float
> _outlet_list
> _outlet_new
> _pd_new
> _post
> _s_list
> collect2: ld returned 1 exit status
> 
> Any advice would be lovely.
> 
> cheers
> dafydd
> 
> On 4/27/06, Hans-Christoph Steiner <hans at eds.org> wrote:
> 
>>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
>>
>>
>>_______________________________________________
>>PD-list at iem.at mailing list
>>UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>
> 
> 
> 
> --
> www.sideshowmedia.ca
> 
> _______________________________________________
> PD-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>