liblo-devel Mailing List for LibLO

On Wed, Aug 25, 2010 at 1:11 PM, RJ Ryan <rr...@mi...> wrote:
> Hi all,
> I was able to get liblo compiling for the Cortex M3, and now I have a number
> of Leaflabs Maple boards controlling a lighting setup using OSC over 802.11
> wireless. It was pretty simple. I went with your suggestion, Stephen, of
> just leaving out send.c and server.c. Unfortunately for now I just decode
> the message manually and go through a list of handlers. It's not nearly as
> robust as the message dispatching in server.c. Maybe at some point I'll look
> at porting it, but it was too tied into the socket logic.
> All I had to do to get the rest compiling was set my config.h correctly to
> reflect what header files I had or didn't have. I also had to strip out all
> includes of network and pthread headers. I typedef'd socklen_t, pthread_t,
> and sockaddr_storage to dummy types because lo_server in lo_types_internal.h
> used these (I didn't bother stripping lo_server out because I'd like to
> re-implement it eventually).
> It's working great! I'm bombarding it with hundreds of messages per second.
> Thanks for the advice,
> RJ Ryan


Great news!  Thanks for the update.

I'd love to try something similar in my research lab.  The Maple
boards look pretty interesting for embedded control, we'll have to get
one to play with ;)

Steve

Hi all,

I was able to get liblo compiling for the Cortex M3, and now I have a number
of Leaflabs Maple <" rel="nofollow">http://leaflabs.com/devices/> boards controlling a
lighting setup using OSC over 802.11 wireless. It was pretty simple. I went
with your suggestion, Stephen, of just leaving out send.c and server.c.
Unfortunately for now I just decode the message manually and go through a
list of handlers. It's not nearly as robust as the message dispatching in
server.c. Maybe at some point I'll look at porting it, but it was too tied
into the socket logic.

All I had to do to get the rest compiling was set my config.h correctly to
reflect what header files I had or didn't have. I also had to strip out all
includes of network and pthread headers. I typedef'd socklen_t, pthread_t,
and sockaddr_storage to dummy types because lo_server in lo_types_internal.h
used these (I didn't bother stripping lo_server out because I'd like to
re-implement it eventually).

It's working great! I'm bombarding it with hundreds of messages per second.

Thanks for the advice,
RJ Ryan

On Thu, Aug 12, 2010 at 11:53 AM, Stephen Sinclair <rad...@gm...>wrote:

> On Wed, Aug 11, 2010 at 5:07 PM, RJ Ryan <rr...@mi...> wrote:
> > Hey Steve,
> > Basically, none of the niceties of POSIX are there. No sockets, no poll,
> not
> > even gettimeofday().
> > I've just finished reading mostly all of the liblo source, and it looks
> to
> > me like send.c and server.c are going to need major surgery to rework
> them
> > so they do not use sockets. Everything 'above' this in liblo looks like
> > it'll be fine to use, with the exception of timetag.c, which relies on
> > time.h. Essentially, all that is available to me is a stripped down libc,
> so
> > at least malloc and calloc are there.
> > http://www.sics.se/~adam/uip/uip-1.0-refman/
> > There's the main uIP documentation. The closest thing they have to a
> socket
> > is a 'protosocket', which besides only being usable for TCP (which makes
> it
> > not very useful in my application) have some major limitations which make
> > them less useful than sockets. There's a nice description of them in the
> uIP
> > docs.
> > Since uIP doesn't provide sockets, the normal way liblo's 'server'
> concept
> > works is going to need to be inverted a little bit. Some event loop
> polling
> > the network for data will push new datagrams destined for liblo into the
> > liblo server, which will then parse them and deliver them.
> > I'd appreciate any input and advice you all have.
>
> Hi, I'd suggest then that you should try to "carve out" the
> socket-related stuff in liblo and use only the parts that serialize
> and deserialize from memory.  (lo_message_serialise and
> lo_server_dispatch_data)  Actually if you can organize this in any
> coherent way (it's probably non-trivial), it would be interesting to
> come up with a patch making it possible to compile liblo with
> conditional socket support, specifically for use on microcontrollers.
> I have thought of doing this myself in the past but haven't gotten
> around to it.
>
> One thing you won't get around easily is the fact that liblo uses
> quite a few mallocs and reallocs during message parsing, so I hope
> that is not a problem.
>
> Steve
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

On Sat, Aug 14, 2010 at 1:46 PM, Morgan Sutherland <ski...@gm...> wrote:
> [1] Stephen, I've been casually looking for a reference on the thresholds at
> which various human organs can distinguish between events in time. I recall
> being told that the skin can distinguish events at the sub-ms timescale, the
> ear at the ms timescale (though, it's complicated with tone formation), and
> the eyes at the 10 or 100-ms timescale. I suspect you've come across
> research like this before.

The only one that comes to mind immediately is this paper on
audio-haptic asynchrony.  I know there has been lots of research about
telling apart audio events, but I can't think of any specific
recommended reading right now.  (I'd just hit google scholar with a
few queries on psychoacoustics.)  There may be some references in the
CNMAT work on timing-related issues?

http://hsi.arc.nasa.gov/publications/Adelstein_2003_Haptic_Audio_Asynchrony.pdf

Steve

On Fri, Aug 13, 2010 at 11:43 PM, RJ Ryan <rr...@mi...> wrote:

> I've been trying to figure out how I could layer in two build flags
> HAVE_SOCKETS and HAVE_PTHREADS, but I'm not sure if there's an easy way to
> do it that would be worthwhile for future people using the library. Maybe
> just a flag that turns off compilation of all server and threading code
> would be the way to go. That way, someone on a platform like this would only
> need some basic libc to do parsing / serialization of OSC messages.   As of
> now, for example pthread.h gets included via lo/lo.h which prevents
> compilation even if server.c and send.c are left out of compilation.

This is basically what I was thinking.  (Like i said I haven't looked
very deeply into it, I know it's probably not straight-forward.)
Would it be a problem to have an #ifdef in the header as well as the
source?  Actually though, a quick grep through lo/*.h doesn't show
anything that seems to use pthread_t or the like, (indeed that should
be internal to lo_server_thread), so maybe that pthread.h doesn't need
to be included at all..

Steve

Thanks for the tip, Morgan. I'm taking a look at the uOSC code now. From
what I've read sofar, it's more of a way to provide remote control of all of
a microcontroller's facilities (IO, ADC, PWM, etc) via OSC. While this is
attractive, I think porting liblo might be faster since I only need to
control the PWM outputs. Plus, since I'm controlling lighting fixtures, it
will be helpful to write a few low-level animation primitives into a little
program + liblo.

I've been trying to figure out how I could layer in two build flags
HAVE_SOCKETS and HAVE_PTHREADS, but I'm not sure if there's an easy way to
do it that would be worthwhile for future people using the library. Maybe
just a flag that turns off compilation of all server and threading code
would be the way to go. That way, someone on a platform like this would only
need some basic libc to do parsing / serialization of OSC messages.   As of
now, for example pthread.h gets included via lo/lo.h which prevents
compilation even if server.c and send.c are left out of compilation.

Thanks,
RJ Ryan



On Thu, Aug 12, 2010 at 9:20 PM, Morgan Sutherland <ski...@gm...>wrote:

> RJ,
>
> You might have a look at micro-OSC from CNMAT: <
> ." rel="nofollow">http://cnmat.berkeley.edu/research/uosc>. They have a
> reference-implementation of OSC for  32-bit PIC and incomplete
> implementations for AVR. It may be easier to port that code.
>
> Not to discourage you from hacking on the liblo code – the proposed
> contribution would be very valuable!
>
> Cheers,
> Morgan
>
> On Wed, Aug 11, 2010 at 4:26 PM, RJ Ryan <rr...@mi...> wrote:
>
>> Hi all,
>>
>> I'm working on getting liblo working on a Cortex M3 ARM CPU. The network
>> stack I'm working with is uIP. Has anybody ever ported liblo to use either
>> lwIP or uIP?
>>
>> Thanks,
>> RJ Ryan
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>

RJ,

You might have a look at micro-OSC from CNMAT: <
." rel="nofollow">http://cnmat.berkeley.edu/research/uosc>. They have a
reference-implementation of OSC for  32-bit PIC and incomplete
implementations for AVR. It may be easier to port that code.

Not to discourage you from hacking on the liblo code – the proposed
contribution would be very valuable!

Cheers,
Morgan

On Wed, Aug 11, 2010 at 4:26 PM, RJ Ryan <rr...@mi...> wrote:

> Hi all,
>
> I'm working on getting liblo working on a Cortex M3 ARM CPU. The network
> stack I'm working with is uIP. Has anybody ever ported liblo to use either
> lwIP or uIP?
>
> Thanks,
> RJ Ryan
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>

On Wed, Aug 11, 2010 at 5:07 PM, RJ Ryan <rr...@mi...> wrote:
> Hey Steve,
> Basically, none of the niceties of POSIX are there. No sockets, no poll, not
> even gettimeofday().
> I've just finished reading mostly all of the liblo source, and it looks to
> me like send.c and server.c are going to need major surgery to rework them
> so they do not use sockets. Everything 'above' this in liblo looks like
> it'll be fine to use, with the exception of timetag.c, which relies on
> time.h. Essentially, all that is available to me is a stripped down libc, so
> at least malloc and calloc are there.
> http://www.sics.se/~adam/uip/uip-1.0-refman/
> There's the main uIP documentation. The closest thing they have to a socket
> is a 'protosocket', which besides only being usable for TCP (which makes it
> not very useful in my application) have some major limitations which make
> them less useful than sockets. There's a nice description of them in the uIP
> docs.
> Since uIP doesn't provide sockets, the normal way liblo's 'server' concept
> works is going to need to be inverted a little bit. Some event loop polling
> the network for data will push new datagrams destined for liblo into the
> liblo server, which will then parse them and deliver them.
> I'd appreciate any input and advice you all have.

Hi, I'd suggest then that you should try to "carve out" the
socket-related stuff in liblo and use only the parts that serialize
and deserialize from memory.  (lo_message_serialise and
lo_server_dispatch_data)  Actually if you can organize this in any
coherent way (it's probably non-trivial), it would be interesting to
come up with a patch making it possible to compile liblo with
conditional socket support, specifically for use on microcontrollers.
I have thought of doing this myself in the past but haven't gotten
around to it.

One thing you won't get around easily is the fact that liblo uses
quite a few mallocs and reallocs during message parsing, so I hope
that is not a problem.

Steve

Hey Steve,

Basically, none of the niceties of POSIX are there. No sockets, no poll, not
even gettimeofday().

I've just finished reading mostly all of the liblo source, and it looks to
me like send.c and server.c are going to need major surgery to rework them
so they do not use sockets. Everything 'above' this in liblo looks like
it'll be fine to use, with the exception of timetag.c, which relies on
time.h. Essentially, all that is available to me is a stripped down libc, so
at least malloc and calloc are there.

http://www.sics.se/~adam/uip/uip-1.0-refman/

There's the main uIP documentation. The closest thing they have to a socket
is a 'protosocket', which besides only being usable for TCP (which makes it
not very useful in my application) have some major limitations which make
them less useful than sockets. There's a nice description of them in the uIP
docs.

Since uIP doesn't provide sockets, the normal way liblo's 'server' concept
works is going to need to be inverted a little bit. Some event loop polling
the network for data will push new datagrams destined for liblo into the
liblo server, which will then parse them and deliver them.

I'd appreciate any input and advice you all have.

Thanks,
RJ

On Wed, Aug 11, 2010 at 4:43 PM, Stephen Sinclair <rad...@gm...>wrote:

> On Wed, Aug 11, 2010 at 4:26 PM, RJ Ryan <rr...@mi...> wrote:
> > Hi all,
> > I'm working on getting liblo working on a Cortex M3 ARM CPU. The network
> > stack I'm working with is uIP. Has anybody ever ported liblo to use
> either
> > lwIP or uIP?
>
> Not myself, but I'm interested in this.  Does this network stack
> differ significantly from the POSIX socket API?
>
> Steve
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

On Wed, Aug 11, 2010 at 4:26 PM, RJ Ryan <rr...@mi...> wrote:
> Hi all,
> I'm working on getting liblo working on a Cortex M3 ARM CPU. The network
> stack I'm working with is uIP. Has anybody ever ported liblo to use either
> lwIP or uIP?

Not myself, but I'm interested in this.  Does this network stack
differ significantly from the POSIX socket API?

Steve

Hi all,

I'm working on getting liblo working on a Cortex M3 ARM CPU. The network
stack I'm working with is uIP. Has anybody ever ported liblo to use either
lwIP or uIP?

Thanks,
RJ Ryan