[PD] osc objects

dafydd hughes dafydd at sideshowmedia.ca
Thu Apr 27 21:36:36 CEST 2006


Hi Martin

Thanks for the help.  For some reason gcc complains about the -shared
option (says it's unrecognized).  Any OSXers have any ideas?

cheers
dafydd

On 4/27/06, Martin Peach <martinrp at vax2.concordia.ca> wrote:
> 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
> >
>
>


--
www.sideshowmedia.ca




More information about the Pd-list mailing list