liblo-devel Mailing List for LibLO

Hi,

I'm new here.  I'm one of the developers of RTcmix <rtcmix.org>.
I've just implemented an OSC server within RTcmix using liblo.
Nice job!  It was really easy to understand and integrate into
our project.

I want to respond to a post from August about the use of
lo_server_thread_del_method() -- more specifically, about the
ability to have multiple callbacks for a single path and type.

Here's some context...

> From: Steve Harris
> Re: lo_server_thread_del_method()  
> 2005-08-22 14:07
> 
> On Mon, Aug 22, 2005 at 06:48:26 +0100, Martin Habets wrote:
> > On Sat, Aug 20, 2005 at 11:20:33AM +0100, Steve Harris wrote:
> > > The arguments that are used to pick the method to remove are the path and
> > > typespec, which seems reasonable, but it is (currently) possible to have
> > > more than one method bound to a particular path and typespec. I dont know
> > > if anyone does that though.
> > 
> > I did not know this was possible (and don't use it). Can't think of a proper
> > way (as in functional strength) to use multiple methods for one path.
> 
> I modelled it after the apache module API, you return a 0, indicating that
> you've handled it, or a 1 indicating that it should fall through to other
> methods that match the incoming message.
> 
> Its not a requirement that you fully specify the path and typespec.
> OTOH I was just speculating about what features would be useful.
> 
> > > lo_server_thread_add_method() returns a lo_method, which I intended to be
> > > used to remote it later, though I can see that might be inconvienient to
> > > hold on to just so you can remove it later.
> > > 
> > > Thoughts?
> > 
> > It all depends on the reason for removing methods. Is there a scenario
> > where someone would want to remove just one method bound to a path+typespec,
> > and not all of them?
> > In my mind one path maps to one method, cause I like to keep things simple.
> 
> Sure, that certianly seems to be the most common usage pattern. I was
> curious to see what peoples programming models are.
> 
> - Steve
 
In RTcmix, which you use in one mode by writing a script in one of 
several supported languages, we have a user function that creates a
stream of data from an OSC specification and lets you store that stream
into a variable for use elsewhere.  The stream is designed to be a
stream of single numbers -- for example, a stream of floats.

We provide a way for the user to specify which number they want to pluck
out of an OSC message that might contain many items.  For example, in a
P5 glove driver I've used (p5osc, I think), there is a single path that
contains nine or ten pieces of data from the glove.  Each RTcmix OSC
stream grabs one piece of data.  Internally, this is implemented by
having a separate callback for each piece of data, requiring that we
make use of the Apache-inspired ability described by Steve above (letting
a single message be matched by multiple methods).  We do this because
of the design of RTcmix's control streams, which I won't go into here.

I could argue that the design of this glove driver is wrong, and that
it should have a separate path for each piece of data.  But since it
exists, I want to support it (and other such things).

So please don't remove this multiple-method feature!  ;-)

As far as the lo_server_thread_del_method, we don't use it.  But I can
see how someone might want to remove just one of several methods that
match the same path/type combination.  Perhaps there could be an additional
function that removes a method based on the lo_method returned
by lo_server_thread_add_method(), as Steve suggested.

Thanks!

-John


------------------------------------------------------------
John Gibson 
Assistant Director, Center for Electronic and Computer Music
Indiana University Jacobs School of Music
Bloomington, IN 47401
www.john-gibson.com