liblo-devel Mailing List for LibLO

Hi Stephen,

Thanks for your considered comments...

On Tue, 2008-12-30 at 13:08 -0500, Stephen Sinclair wrote:
> It looks like it's going in the right direction, but I have some comments.
> First though, what would you change in the function names?  

Hm, tricky...  Maybe lo_stamped_method_handler?

This all seems a little messy though.  The way I see it,
lo_method_handler should be passed the timestamp, but that would need an
API change.  Another idea is to intead add lo_method_handler_p (or
similar) that gets parameters in a struct.  The timestamp could go in
there, as could any future info without breaking existing code.  

Something like: 

typedef struct {
        const char *path;
        const char *types, lo_arg **argv;
        int argc;
        struct _lo_message *msg;
        void *user_data;
        lo_timetag *tt;
} lo_message_p;

typedef int (*lo_method_handler_p)(lo_message_p *p);

Does that make sense to you?

> One thing
> I might have done differently is add the timetag parameter last,
> instead of first.

I'd be happy to change that if we stick with this patch.  My reasoning
for adding it first is because it comes first in the bundle.

> Also, could you add some documentation, clearly describing the
> difference between a normal method and a timetag method?

Yes for sure.  I was going to wait for your comments but now realise not
documenting makes it harder to review...

> This patch seems to add a new method type that is called exactly the
> same way as normal methods, but includes timetag information.  

That's right.

> Correct
> me if I'm wrong, but I thought the idea was to avoid queuing timetag
> method calls, so that they can be for example used in message
> forwarding.

Well there's two problems.  One is as you describe, that in some cases
you might want to handle queueing elsewhere.  Another is that bundled
messages don't have access to the timetag.  That's what I'm fixing here.

I see these as separate problems, because you might want to use liblo's
message queue but still know the timestamps.  In fact, that's what I now
want to do.  I'd like to sync with supercollider, which substracts a
fixed global latency (default 0.2 seconds) from all timestamps, giving
time for calculation.  That is, the timestamps reflect when calculation
should begin, and the calculation code adds the global latency to the
timestamp to find when the samples should actually start being written
out.  

Well that's how I understand it -- I'm not an sclang programmer, but am
working with a friend who is.  We're trying to get a simple way of
syncing software together.  So far we have sclang, perl and haskell
syncing nicely, and I'd love to add C to the list via liblo.  A preview
of our workings is here: http://netclock.slab.org/

> I realize this means actually doing method matching on receipt of a
> message, instead of just comparing timetags simply, so maybe it's not
> a very efficient thing to do.
> 
> It may also mean separating out the method matching code in
> dispatch_method() from the actual handler call, which might be a good
> idea anyway.  Perhaps if timetag handlers were kept in a separate
> list, so that it's not necessary to search through all registered
> handlers to find whether a timetag method is matched?

Well now I've better understood things, I'm happy with the queuing in
liblo the way it is (with Dominic's patch).  Until there's a clear use
case for turning off the queueing perhaps there's no point in
complicating things.

> I'm not sure this if statement really adds anything.

Oops!  I confess to being inexperienced with unions.

Cheers,

alex

On Mon, Dec 29, 2008 at 6:32 PM, Nicholas J Humfrey <nj...@ae...> wrote:
>
> While I appreciate the need for extra functionality, the liblo API is
> starting to balloon and loosing its Lightweightness.
>
> Should we perhaps consider the lessons learnt and create a version 2
> of the API?

I'm not personally convinced this is necessary, but I'd be happy to
hear whether anyone else has an opinion here.  I can think of only a
few things that could be collapsed in the API into fewer function
definitions: multicast, timetag information for handlers (in
progress).  Things like setting the multicast TTL could be moved into
low-level.  Otherwise the high-level API only really consists of about
25 functions, most of which are new/free, add/del, and start/stop
pairs.  I'd hardly call this bloated.

I'll admit that one thing I've always found weird about LibLo is how
it encourages the use of threads without making any suggestions
towards proper locking.  I find this pretty misleading for less
experienced developers who may not realize the perils of
multi-threaded programming.  Personally in my code I've begun to
always avoid threads as much as possible, with a preference for
non-blocking I/O.

I did see your suggestion for the "lo_client" API, apologies for not
replying directly to that post yet.  From what I could tell it would
mostly be a pretty thin wrapper around current calls, except for an
additional blocking "get_reply" method.  I can see how this is
impossible to do right now since lo_address and lo_server are
well-separated concepts.  Perhaps a single lo_get_reply() function
which takes both an address and a server as argument?

Either way, I'm not so sure it's good to encourage people to create
synchronous, blocking code.  Sure, it can certainly lead to
cleaner-looking code, but at the expense of either a hanging process
or dealing with threads.  (Languages with closures make this way
easier, for continuation-passing style asynchronous code, but we're
dealing with C here.)


Steve

On Mon, Dec 29, 2008 at 5:02 PM, alex <al...@sl...> wrote:
> On Mon, 2008-12-29 at 00:07 +0000, alex wrote:
>> On Tue, 2008-12-23 at 13:57 -0500, Stephen Sinclair wrote:
>> > Right.  If you want to forward the message, you'd want to use
>> > lo_send_timestamped(), where you'd need the timetag information.
>> >
>> > Gotta put this on my todo list..
>>
>> Ok great.  I have made a quick patch with lo_server_add_timetag_method,
>> will send it to you once I've tested it a bit.
>
> Attached...  Hopefully it's useful although I'm not happy with the
> function names etc.

It looks like it's going in the right direction, but I have some comments.
First though, what would you change in the function names?  One thing
I might have done differently is add the timetag parameter last,
instead of first.

Also, could you add some documentation, clearly describing the
difference between a normal method and a timetag method?

This patch seems to add a new method type that is called exactly the
same way as normal methods, but includes timetag information.  Correct
me if I'm wrong, but I thought the idea was to avoid queuing timetag
method calls, so that they can be for example used in message
forwarding.

I realize this means actually doing method matching on receipt of a
message, instead of just comparing timetags simply, so maybe it's not
a very efficient thing to do.

It may also mean separating out the method matching code in
dispatch_method() from the actual handler call, which might be a good
idea anyway.  Perhaps if timetag handlers were kept in a separate
list, so that it's not necessary to search through all registered
handlers to find whether a timetag method is matched?

Small thing:

@@ -985,8 +998,10 @@
     } else {
        m->typespec = NULL;
     }
-
-    m->handler = h;
+
+    if (h != NULL) {
+        m->handler.method = h;
+    }
     m->user_data = user_data;
     m->next = NULL;

I'm not sure this if statement really adds anything.


thanks!

Steve

On 29 Dec 2008, at 22:02, alex wrote:

> On Mon, 2008-12-29 at 00:07 +0000, alex wrote:
>> On Tue, 2008-12-23 at 13:57 -0500, Stephen Sinclair wrote:
>>> Right.  If you want to forward the message, you'd want to use
>>> lo_send_timestamped(), where you'd need the timetag information.
>>>
>>> Gotta put this on my todo list..
>>
>> Ok great.  I have made a quick patch with  
>> lo_server_add_timetag_method,
>> will send it to you once I've tested it a bit.
>
> Attached...  Hopefully it's useful although I'm not happy with the
> function names etc.
>
> alex


While I appreciate the need for extra functionality, the liblo API is  
starting to balloon and loosing its Lightweightness.

Should we perhaps consider the lessons learnt and create a version 2  
of the API?


nick.

On Mon, 2008-12-29 at 00:07 +0000, alex wrote:
> On Tue, 2008-12-23 at 13:57 -0500, Stephen Sinclair wrote:
> > Right.  If you want to forward the message, you'd want to use
> > lo_send_timestamped(), where you'd need the timetag information.
> > 
> > Gotta put this on my todo list..
> 
> Ok great.  I have made a quick patch with lo_server_add_timetag_method,
> will send it to you once I've tested it a bit.

Attached...  Hopefully it's useful although I'm not happy with the
function names etc.

alex

On Tue, 2008-12-23 at 13:57 -0500, Stephen Sinclair wrote:
> Right.  If you want to forward the message, you'd want to use
> lo_send_timestamped(), where you'd need the timetag information.
> 
> Gotta put this on my todo list..

Ok great.  I have made a quick patch with lo_server_add_timetag_method,
will send it to you once I've tested it a bit.

Cheers,

alex

On Tue, Dec 23, 2008 at 8:27 PM, Stephen Sinclair <rad...@gm...> wrote:
> On Tue, Dec 23, 2008 at 4:46 PM, Steve Harris
> <S.W...@ec...> wrote:
>> On 23 Dec 2008, at 19:03, Stephen Sinclair wrote:

>>> Maybe Steve H. can tell me, but I'm not actually sure what advantage
>>> poll() has over select(), actually.
>>
>> Not really my field, but I used to work without shouting distance of a
>> load of network research people, I asked them and they said "use
>> poll(), it's better" or words to that effect :)
>>
>> I vaguely remember that select is only efficient with a small number
>> of sockets/FDs.
>
>
> Hmm.. :)  Interesting, I personally haven't used poll before at all.
> I looked into it, as I got curious.  It looks like select() is
> basically limited in number of sockets because it uses a bitmask.
>
> Looks like it wasn't necessary before, but if I'm to maintain a list
> of sockets it works well.  I can probably save some coding by using an
> array instead of a linked list and pass it in directly.  (I was trying
> to avoid shuffling array items around, but now that I think about it,
> it's probably a lot more efficient to shuffle an array when
> connections are removed, than to build it from a list every time
> lo_server_recv() is called.)
>
> I think for portability I might change it to use autoconf to detect
> poll() and use it, instead of just assuming it is there on non-Windows
> systems.

I generally use poll() because it comes from the POSIX standard.
Someone recently pointed out to me that POSIX now specifies select()
as well.  That was originally a BSD interface (IIRC).

I think both are probably OK for most purposes.  Poll still seems
slightly better because it handles processes with >32 open files.
-- 
 joq

On Tue, Dec 23, 2008 at 6:48 PM, Nicholas J Humfrey <nj...@ae...> wrote:
> Thanks Steve,
>
> Committed in r141 :)
>
> I saw that the date of your last change in the ChangeLog was 2008-23-11.
> Month and day the wrong way round? I swapped them.


Looks like it, thanks for catching that. :)


Steve

On Tue, Dec 23, 2008 at 4:46 PM, Steve Harris
<S.W...@ec...> wrote:
> On 23 Dec 2008, at 19:03, Stephen Sinclair wrote:
>
>> On Sun, Dec 21, 2008 at 3:17 AM, Kentaro Fukuchi
>> <fu...@me...> wrote:
>>> Hi Steve,
>>>
>>> It's really nice to have a keep-alive TCP connection of OSC server.
>>>
>>> On Wed, 17 Dec 2008 15:59:58 -0500
>>> "Stephen Sinclair" <rad...@gm...> wrote:
>>>
>>>> So that tells me it might be better to leave them open, so I tried
>>>> this.  It worked for a single connection, by adding a
>>>> "connected_socket" member to the lo_server structure, and polling
>>>> that
>>>> instead of the "socket" member.  However, I quickly realized that
>>>> this
>>>> would mean that lo_server would need a data structure to track _all_
>>>> open sockets.
>>>
>>> Common server programs using TCP have the same data structure to
>>> track them.
>>> For blocking server, you can use select() system call.
>>
>> Exactly, it's already using select() for Windows and poll() for *nix,
>> so it should be fairly easy to support this.  I already started
>> working on a patch but it's not ready yet.  So far I'm using a linked
>> list to keep the socket information, but I'm trying to decide if this
>> approach is more complex than necessary.
>>
>> Maybe Steve H. can tell me, but I'm not actually sure what advantage
>> poll() has over select(), actually.
>
> Not really my field, but I used to work without shouting distance of a
> load of network research people, I asked them and they said "use
> poll(), it's better" or words to that effect :)
>
> I vaguely remember that select is only efficient with a small number
> of sockets/FDs.


Hmm.. :)  Interesting, I personally haven't used poll before at all.
I looked into it, as I got curious.  It looks like select() is
basically limited in number of sockets because it uses a bitmask.

Looks like it wasn't necessary before, but if I'm to maintain a list
of sockets it works well.  I can probably save some coding by using an
array instead of a linked list and pass it in directly.  (I was trying
to avoid shuffling array items around, but now that I think about it,
it's probably a lot more efficient to shuffle an array when
connections are removed, than to build it from a list every time
lo_server_recv() is called.)

I think for portability I might change it to use autoconf to detect
poll() and use it, instead of just assuming it is there on non-Windows
systems.

Steve

Thanks Steve,

Committed in r141 :)

I saw that the date of your last change in the ChangeLog was 2008-23-11.
Month and day the wrong way round? I swapped them.

nick.

On 23 Dec 2008, at 19:46, Stephen Sinclair wrote:

> Hey Nick,
>
> Your patch looks fine to me.  Watch one typo in the docs, recieve ->  
> receive.
> Since you have commit access, feel free to commit it or I can do it if
> you prefer.
>
> Steve
>
>
> On Sun, Dec 21, 2008 at 7:15 AM, Nicholas J Humfrey <nj...@ae...>  
> wrote:
>> Hello again,
>>
>> Attached is a patch to add support for lo_server_wait.
>>
>> Are you planning to make a new release any time soon Stephen?
>>
>>
>> Thanks,
>>
>> nick.
>>
>>
>>
>>
>> On 21 Dec 2008, at 00:26, Nicholas J Humfrey wrote:
>>
>>> Hello,
>>>
>>> I would like to propose adding a new method to the liblo API called
>>> lo_server_wait.
>>>
>>> Its implementation would be almost exactly the same as
>>> lo_server_recv_noblock, except it just waits for some data to be  
>>> ready
>>> for processing and does not call lo_server_recv itself. It would
>>> return 1 if there is a message waiting or 0 if it timed out.
>>>
>>> The reason for this is because I am trying to implement OSC  
>>> support in
>>> VLC, but I am having issues with VLC's thread cancelling. VLC  
>>> creates
>>> the thread itself and I am using liblo's low level lo_server
>>> functions. Basically I want the thread to be cancellable while  
>>> waiting
>>> for a message (while lo_server_wait is blocking). But while the
>>> message is being processed (and handlers are being called). I don't
>>> want the thread to be cancellable.
>>>
>>> I don't believe there is a way of doing this at the moment because
>>> waiting for a message and processing that message are the same API
>>> call...
>>>
>>>
>>>
>>> nick.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

On 23 Dec 2008, at 19:03, Stephen Sinclair wrote:

> On Sun, Dec 21, 2008 at 3:17 AM, Kentaro Fukuchi  
> <fu...@me...> wrote:
>> Hi Steve,
>>
>> It's really nice to have a keep-alive TCP connection of OSC server.
>>
>> On Wed, 17 Dec 2008 15:59:58 -0500
>> "Stephen Sinclair" <rad...@gm...> wrote:
>>
>>> So that tells me it might be better to leave them open, so I tried
>>> this.  It worked for a single connection, by adding a
>>> "connected_socket" member to the lo_server structure, and polling  
>>> that
>>> instead of the "socket" member.  However, I quickly realized that  
>>> this
>>> would mean that lo_server would need a data structure to track _all_
>>> open sockets.
>>
>> Common server programs using TCP have the same data structure to  
>> track them.
>> For blocking server, you can use select() system call.
>
> Exactly, it's already using select() for Windows and poll() for *nix,
> so it should be fairly easy to support this.  I already started
> working on a patch but it's not ready yet.  So far I'm using a linked
> list to keep the socket information, but I'm trying to decide if this
> approach is more complex than necessary.
>
> Maybe Steve H. can tell me, but I'm not actually sure what advantage
> poll() has over select(), actually.

Not really my field, but I used to work without shouting distance of a  
load of network research people, I asked them and they said "use  
poll(), it's better" or words to that effect :)

I vaguely remember that select is only efficient with a small number  
of sockets/FDs.

- Steve

Hey Nick,

Your patch looks fine to me.  Watch one typo in the docs, recieve -> receive.
Since you have commit access, feel free to commit it or I can do it if
you prefer.

Steve


On Sun, Dec 21, 2008 at 7:15 AM, Nicholas J Humfrey <nj...@ae...> wrote:
> Hello again,
>
> Attached is a patch to add support for lo_server_wait.
>
> Are you planning to make a new release any time soon Stephen?
>
>
> Thanks,
>
> nick.
>
>
>
>
> On 21 Dec 2008, at 00:26, Nicholas J Humfrey wrote:
>
>> Hello,
>>
>> I would like to propose adding a new method to the liblo API called
>> lo_server_wait.
>>
>> Its implementation would be almost exactly the same as
>> lo_server_recv_noblock, except it just waits for some data to be ready
>> for processing and does not call lo_server_recv itself. It would
>> return 1 if there is a message waiting or 0 if it timed out.
>>
>> The reason for this is because I am trying to implement OSC support in
>> VLC, but I am having issues with VLC's thread cancelling. VLC creates
>> the thread itself and I am using liblo's low level lo_server
>> functions. Basically I want the thread to be cancellable while waiting
>> for a message (while lo_server_wait is blocking). But while the
>> message is being processed (and handlers are being called). I don't
>> want the thread to be cancellable.
>>
>> I don't believe there is a way of doing this at the moment because
>> waiting for a message and processing that message are the same API
>> call...
>>
>>
>>
>> nick.
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>

On Tue, Dec 23, 2008 at 2:23 PM, Nicholas J Humfrey <nj...@ae...> wrote:
>
> On 23 Dec 2008, at 19:17, Stephen Sinclair wrote:
>
>> On Sat, Dec 20, 2008 at 7:26 PM, Nicholas J Humfrey <nj...@ae...>
>> wrote:
>>> Hello,
>>>
>>> I would like to propose adding a new method to the liblo API called
>>> lo_server_recv_wait.
>>>
>>> Its implementation would be almost exactly the same as
>>> lo_server_recv_noblock, except it just waits for some data to be
>>> ready
>>> for processing and does not call lo_server_recv itself. It would
>>> return 1 if there is a message waiting or 0 if it timed out.
>>>
>>> The reason for this is because I am trying to implement OSC support
>>> in
>>> VLC, but I am having issues with VLC's thread cancelling. VLC creates
>>> the thread itself and I am using liblo's low level lo_server
>>> functions. Basically I want the thread to be cancellable while
>>> waiting
>>> for a message (while lo_server_recv_wait is blocking). But while the
>>> message is being processed (and handlers are being called). I don't
>>> want the thread to be cancellable.
>>>
>>> I don't believe there is a way of doing this at the moment because
>>> waiting for a message and processing that message are the same API
>>> call...
>>
>> Couldn't it be done by using lo_server_get_socket_fd() and calling
>> select() on it?
>>
>> This doesn't mean I'm opposed to adding lo_server_wait(), but it seems
>> like that's essentially what it would do.
>
> It is theoretically that simple but if you look at the code for
> lo_server_recv_noblock(), it has the two different implementations for
> Windows and Unix and also checks for scheduled events too.
>
> Seems sensible to separate out that functionality into a reusable
> function.

Right, particularly checking for scheduled events is something that
couldn't be done without liblo's support, that's a good point.

Steve

On 23 Dec 2008, at 19:17, Stephen Sinclair wrote:

> On Sat, Dec 20, 2008 at 7:26 PM, Nicholas J Humfrey <nj...@ae...>  
> wrote:
>> Hello,
>>
>> I would like to propose adding a new method to the liblo API called
>> lo_server_recv_wait.
>>
>> Its implementation would be almost exactly the same as
>> lo_server_recv_noblock, except it just waits for some data to be  
>> ready
>> for processing and does not call lo_server_recv itself. It would
>> return 1 if there is a message waiting or 0 if it timed out.
>>
>> The reason for this is because I am trying to implement OSC support  
>> in
>> VLC, but I am having issues with VLC's thread cancelling. VLC creates
>> the thread itself and I am using liblo's low level lo_server
>> functions. Basically I want the thread to be cancellable while  
>> waiting
>> for a message (while lo_server_recv_wait is blocking). But while the
>> message is being processed (and handlers are being called). I don't
>> want the thread to be cancellable.
>>
>> I don't believe there is a way of doing this at the moment because
>> waiting for a message and processing that message are the same API
>> call...
>
> Couldn't it be done by using lo_server_get_socket_fd() and calling
> select() on it?
>
> This doesn't mean I'm opposed to adding lo_server_wait(), but it seems
> like that's essentially what it would do.

It is theoretically that simple but if you look at the code for  
lo_server_recv_noblock(), it has the two different implementations for  
Windows and Unix and also checks for scheduled events too.

Seems sensible to separate out that functionality into a reusable  
function.


nick.

On Sat, Dec 20, 2008 at 7:26 PM, Nicholas J Humfrey <nj...@ae...> wrote:
> Hello,
>
> I would like to propose adding a new method to the liblo API called
> lo_server_recv_wait.
>
> Its implementation would be almost exactly the same as
> lo_server_recv_noblock, except it just waits for some data to be ready
> for processing and does not call lo_server_recv itself. It would
> return 1 if there is a message waiting or 0 if it timed out.
>
> The reason for this is because I am trying to implement OSC support in
> VLC, but I am having issues with VLC's thread cancelling. VLC creates
> the thread itself and I am using liblo's low level lo_server
> functions. Basically I want the thread to be cancellable while waiting
> for a message (while lo_server_recv_wait is blocking). But while the
> message is being processed (and handlers are being called). I don't
> want the thread to be cancellable.
>
> I don't believe there is a way of doing this at the moment because
> waiting for a message and processing that message are the same API
> call...

Couldn't it be done by using lo_server_get_socket_fd() and calling
select() on it?

This doesn't mean I'm opposed to adding lo_server_wait(), but it seems
like that's essentially what it would do.


Steve

On Sun, Dec 21, 2008 at 7:15 AM, Nicholas J Humfrey <nj...@ae...> wrote:
> Hello again,
>
> Attached is a patch to add support for lo_server_wait.

Thanks, I'll take a look at it.
Sorry for the delay, it's paradoxically been hard to find free time
during the holidays. :)

> Are you planning to make a new release any time soon Stephen?

I'd like to.  Things I'd like to finish dealing with are the timetag
bug (straight-forward, as discussed), a better TCP implementation, and
perhaps supporting unqueued messages.  I want to do some more testing
on Windows and OS X as well.

Here's an annotated list of changes so far since 0.25:

- Fixed some bugs, memory leaks, compilation errors/warnings
- Fixed up documentation quite a bit
- Allow retrieval of the protocol ID number of a URL. (Kentaro Fukuchi)
- Expose the lo_server_dispatch_data() function as public.
- Move lo_arg_size(), lo_get_path(), lo_arg_host/network_endian() back
to lo_lowlevel.h.
- With permission of all authors, the license of LibLo has changed to
the LGPL 2.1 or later.

Now that I look at that list, perhaps 0.26 should be done soon, and
considered a maintenance release.  Particularly for the license
change.  The other reason I want to get a new version out there is
because I messed up last time updating the library's "soname", which
is apparently the reason that it hasn't been updated in Debian since
0.23.

I think I'll see how much we can get done on some outstanding issues
during the holidays, and do a release in early January.  Does that
sound good to everyone?


Steve

On Sun, Dec 21, 2008 at 3:17 AM, Kentaro Fukuchi <fu...@me...> wrote:
> Hi Steve,
>
> It's really nice to have a keep-alive TCP connection of OSC server.
>
> On Wed, 17 Dec 2008 15:59:58 -0500
> "Stephen Sinclair" <rad...@gm...> wrote:
>
>> So that tells me it might be better to leave them open, so I tried
>> this.  It worked for a single connection, by adding a
>> "connected_socket" member to the lo_server structure, and polling that
>> instead of the "socket" member.  However, I quickly realized that this
>> would mean that lo_server would need a data structure to track _all_
>> open sockets.
>
> Common server programs using TCP have the same data structure to track them.
> For blocking server, you can use select() system call.

Exactly, it's already using select() for Windows and poll() for *nix,
so it should be fairly easy to support this.  I already started
working on a patch but it's not ready yet.  So far I'm using a linked
list to keep the socket information, but I'm trying to decide if this
approach is more complex than necessary.

Maybe Steve H. can tell me, but I'm not actually sure what advantage
poll() has over select(), actually.


>> I'll probably play with it a little more this week, but any ideas are
>> welcome.  Does anyone have any experience with other TCP
>> implementations of OSC?  I'd like it if TCP was useable between
>> different implementations.
>
> OscP5 seems to have a keep-alive TCP connection support. I just quickly
> read the source and didn't test it.

Thanks for pointing that out, I hadn't even heard of this implementation.
I haven't used Processing, but it certainly seems like fun. :)

Steve

On Wed, Dec 17, 2008 at 6:49 AM, alex <al...@sl...> wrote:
>
> Hi Stephen,
>
> On Wed, 2008-12-10 at 22:58 -0500, Stephen Sinclair wrote:
>> Okay, general problems with timestamps aside, let's aim to at least
>> fix this bug before the next release.  I'll have to set down a few
>> specific goals for the next release, and I think this will definitely
>> be one of them since it seems we could nail it down soon.  If the
>> suggested change in the bug tracker is right, maybe that's that.
>
> Yes I think Dominic has it fixed.
>
>> But first, do you think it's feasible to create a test in the testlo.c
>> program that would identify mishandled timestamps?  For most bugs, I
>> have been trying to always add something to testlo that will break it,
>> before investigating the actual fix.
>
> I wrote a test to check that the bundles arrive in the right order
> according to the timetag.  Unfortunately it seems that they _do_ arrive
> in order, even without the patch, so I haven't got a failing test for
> you...
>
>> Second, I don't mind the idea of making timestamp queuing optional.
>> It seems that message forwarding is a common enough request that it
>> should be handled well by LibLo.  Does anyone have any API
>> suggestions?  It could be a boolean for lo_server, something like
>> lo_server_queueing_enabled().  Though I'm not convinced this will
>> cover all possible use cases, so it would be good to give some more
>> thought before adding to the API.
>
> That would be good for me, but the message also needs to know its
> 'logical time', which might then be in the future.
>
> Howabout adding a new method handler type that accepts a timetag (set to
> NULL for unbundled messages)?  Then lo_sever_add_timetag_method for
> registering a handler?
>
> lo_timetag_method lo_server_add_timetag_method(lo_server s,
>                                               const char *path,
>                                               const char *typespec,
>                                               lo_timetag_method_handler h,
>                                               void *user_data
>                                              );
>
> typedef int (*lo_timetag_method_handler)(lo_timetag *tt, const char *path,
>                                         const char *types,
>                                         lo_arg **argv, int argc, struct _lo_message
>                                         *msg, void *user_data);
>

Right.  If you want to forward the message, you'd want to use
lo_send_timestamped(), where you'd need the timetag information.

Gotta put this on my todo list..


Steve

Yeah I hadn't even realized the #reply functionality was there until
very recently when I was browsing the source code for a different
reason.

I'm watching that discussion on OSC_dev, and I'll be interested in
discussing further development in LibLo, if anything comes of it.
However I'm pretty wary of putting anything in LibLo that isn't in a
standard, since these things may as well be application-dependent if
they're not going to be standardized.

That was also my reason for not immediately accepting the Avahi patch
that someone posted a while ago---I still think it's a good idea, but
I want to make sure it follows some agreement with the rest of the
community.

Steve


On Sun, Dec 21, 2008 at 5:46 PM, Steve Harris
<S.W...@ec...> wrote:
> That's the one.
>
> To be perfectly honest it didn't seem that well thought out, but I
> felt that OSC was really lacking some kind of schema/discovery
> specification, and something is better than nothing.
>
> - Steve
>
> On 21 Dec 2008, at 01:19, Nicholas J Humfrey wrote:
>
>> Reply on OSC_dev mailing list:
>>
>>
>>> #reply was first proposed in this 2004 paper by Andy W. Schmeder and
>>> Matt Wright:
>>>
>>> http://opensoundcontrol.org/publication/query-system-open-sound-
>>> control
>>>
>>
>>
>> On 20 Dec 2008, at 23:35, Nicholas J Humfrey wrote:
>>
>>> Hello,
>>>
>>> I suspect that Steve Harris may be the only person who can answer
>>> this, but I thought I would send it to the mailing list and see what
>>> others think too.
>>>
>>>
>>> There has been some discussion about replies and service discovery on
>>> the OSC devel mailing list. And I remembered that liblo already
>>> supported some of it.
>>>
>>> If you send any liblo application a message that ends with a slash
>>> (and it doesn't match any application handlers) then it will respond
>>> with a #reply message that lists the installed handlers that exist in
>>> that path level.
>>>
>>> -> /foo/bar
>>> <- #reply ssss /foo/ one two three
>>>
>>>
>>> Is this based on some kind of proposed standard? It doesn't seem to
>>> be
>>> part of "The Open Sound Control 1.0 Specification".
>>>
>>>
>>> nick.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> liblo-devel mailing list
>>> lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>

That's the one.

To be perfectly honest it didn't seem that well thought out, but I  
felt that OSC was really lacking some kind of schema/discovery  
specification, and something is better than nothing.

- Steve

On 21 Dec 2008, at 01:19, Nicholas J Humfrey wrote:

> Reply on OSC_dev mailing list:
>
>
>> #reply was first proposed in this 2004 paper by Andy W. Schmeder and
>> Matt Wright:
>>
>> http://opensoundcontrol.org/publication/query-system-open-sound-
>> control
>>
>
>
> On 20 Dec 2008, at 23:35, Nicholas J Humfrey wrote:
>
>> Hello,
>>
>> I suspect that Steve Harris may be the only person who can answer
>> this, but I thought I would send it to the mailing list and see what
>> others think too.
>>
>>
>> There has been some discussion about replies and service discovery on
>> the OSC devel mailing list. And I remembered that liblo already
>> supported some of it.
>>
>> If you send any liblo application a message that ends with a slash
>> (and it doesn't match any application handlers) then it will respond
>> with a #reply message that lists the installed handlers that exist in
>> that path level.
>>
>> -> /foo/bar
>> <- #reply ssss /foo/ one two three
>>
>>
>> Is this based on some kind of proposed standard? It doesn't seem to  
>> be
>> part of "The Open Sound Control 1.0 Specification".
>>
>>
>> nick.
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> liblo-devel mailing list
>> lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hello,

Replying is quite messy in liblo. I propose moving lo_address* and  
lo_send into the Low Level API and adding a new lo_client set of  
methods to the High Level API.


Here are is an example:

lo_client *client = lo_client_new("osc.udp://foo.example.com:4444");

// Optional, set the reply timeout
lo_client_set_timeout( client, 1000 );

// Send a message without waiting for a reply
lo_client_send(client, "/a/b/c/d", "sf", "one", 1.0);

// Send message and wait for reply
lo_message *reply = lo_client_query(client, "/patch1/gain1/#current- 
value");

lo_client_free(client);



Perhaps lo_client_new should take a URL and should take a host, port  
and protocol instead?
Anything else we can improve/simplify at the same time?


Pending discussions on the OSC_dev mailing list, it might be cool to  
make it easier to get (#current-value) using:

lo_arg value = lo_client_get_value(client, "/patch1/gain1");



nick.

Hello again,

Attached is a patch to add support for lo_server_wait.

Are you planning to make a new release any time soon Stephen?


Thanks,

nick.

Hi Steve,

It's really nice to have a keep-alive TCP connection of OSC server.

On Wed, 17 Dec 2008 15:59:58 -0500
"Stephen Sinclair" <rad...@gm...> wrote:

> So that tells me it might be better to leave them open, so I tried
> this.  It worked for a single connection, by adding a
> "connected_socket" member to the lo_server structure, and polling that
> instead of the "socket" member.  However, I quickly realized that this
> would mean that lo_server would need a data structure to track _all_
> open sockets.

Common server programs using TCP have the same data structure to track them.
For blocking server, you can use select() system call.

> I'll probably play with it a little more this week, but any ideas are
> welcome.  Does anyone have any experience with other TCP
> implementations of OSC?  I'd like it if TCP was useable between
> different implementations.

OscP5 seems to have a keep-alive TCP connection support. I just quickly
read the source and didn't test it.

Kentaro

Reply on OSC_dev mailing list:


> #reply was first proposed in this 2004 paper by Andy W. Schmeder and  
> Matt Wright:
>
> http://opensoundcontrol.org/publication/query-system-open-sound- 
> control
>


On 20 Dec 2008, at 23:35, Nicholas J Humfrey wrote:

> Hello,
>
> I suspect that Steve Harris may be the only person who can answer
> this, but I thought I would send it to the mailing list and see what
> others think too.
>
>
> There has been some discussion about replies and service discovery on
> the OSC devel mailing list. And I remembered that liblo already
> supported some of it.
>
> If you send any liblo application a message that ends with a slash
> (and it doesn't match any application handlers) then it will respond
> with a #reply message that lists the installed handlers that exist in
> that path level.
>
> -> /foo/bar
> <- #reply ssss /foo/ one two three
>
>
> Is this based on some kind of proposed standard? It doesn't seem to be
> part of "The Open Sound Control 1.0 Specification".
>
>
> nick.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hello,

I would like to propose adding a new method to the liblo API called  
lo_server_recv_wait.

Its implementation would be almost exactly the same as  
lo_server_recv_noblock, except it just waits for some data to be ready  
for processing and does not call lo_server_recv itself. It would  
return 1 if there is a message waiting or 0 if it timed out.

The reason for this is because I am trying to implement OSC support in  
VLC, but I am having issues with VLC's thread cancelling. VLC creates  
the thread itself and I am using liblo's low level lo_server  
functions. Basically I want the thread to be cancellable while waiting  
for a message (while lo_server_recv_wait is blocking). But while the  
message is being processed (and handlers are being called). I don't  
want the thread to be cancellable.

I don't believe there is a way of doing this at the moment because  
waiting for a message and processing that message are the same API  
call...



nick.