liblo-devel Mailing List for LibLO

The easiest way is of course to specify variables as parameters, rather than as parts of the path. Many existing applications use that kind of scheme. But I can certainly understand the aesthetics of wildcard paths – I wanted to do the same in a recent project, but eventually I abandoned the idea in favor of using something more like

/channel/mixer/audio/dBFS [i] [i] [f]

(using your example)

Erik



> 29 sep 2015 kl. 16:33 skrev Steve Harris <s.w...@ec...>:
> 
> From what I remember (it’s a few years ago now!) the intention was that you register the same handler for multiple paths:
> 
> lo_server_thread_add_method(st, "/channel/*/mixer/audio/1/dBFS", "f", mixer_handler, NULL);
> lo_server_thread_add_method(st, "/channel/*/mixer/audio/2/dBFS", "f", mixer_handler, NULL);
> lo_server_thread_add_method(st, "/channel/*/mixer/audio/3/dBFS", "f", mixer_handler, NULL);
> …
> 
> As someone else said, the wildcards are for incoming messages, not handlers. You can’t do wildcard-to-wildcard matching, obviously.
> 
> When the handler is called, it’s told what path it was called from. If you want more context, that’s what the user_data field is for - you could pass in a pointer to the channel number to save you parsing the path for e.g.
> 
> - Steve
> 
>> On 28 Sep 2015, at 23:12, Carl z! Zwanzig <zb...@so...> wrote:
>> 
>> Hi,
>> 
>> On 9/28/2015 12:24 PM, Erik Ronström wrote:
>>> In the original OSC spec, pattern matching is used the other way round:
>>> handlers have absolute paths, while messages can use wildcard paths, in
>>> which case they are dispatched to all matching handlers.
>> 
>> Actually, I wasn't aware of that (will have to look at the spec again). The 
>> code (server.c, dispatch_method) has a check as to whether the path contains 
>> a wildcard character:
>> 
>> 1711:    int pattern = strpbrk(path, " #*,?[]{}") != NULL;
>> 
>> but it's not clear to me whether this is the path out of the received 
>> message or as defined to lo_server_thread_add_method.
>> 
>> 
>> Anyway, is there a better way to do this? I'd like to have one handler that 
>> gets all "/channel/*/mixer/audio/*" messages and another that gets 
>> "/channel/*/stage/layer/*/*" messages. My workarounds are to either separate 
>> them in a single handler or add separate handlers for each message, which 
>> seems inefficient.
>> 
>> Thanks,
>> 
>> z!
>> 
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> 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

From what I remember (it’s a few years ago now!) the intention was that you register the same handler for multiple paths:

lo_server_thread_add_method(st, "/channel/*/mixer/audio/1/dBFS", "f", mixer_handler, NULL);
lo_server_thread_add_method(st, "/channel/*/mixer/audio/2/dBFS", "f", mixer_handler, NULL);
lo_server_thread_add_method(st, "/channel/*/mixer/audio/3/dBFS", "f", mixer_handler, NULL);
…

As someone else said, the wildcards are for incoming messages, not handlers. You can’t do wildcard-to-wildcard matching, obviously.

When the handler is called, it’s told what path it was called from. If you want more context, that’s what the user_data field is for - you could pass in a pointer to the channel number to save you parsing the path for e.g.

- Steve

> On 28 Sep 2015, at 23:12, Carl z! Zwanzig <zb...@so...> wrote:
> 
> Hi,
> 
> On 9/28/2015 12:24 PM, Erik Ronström wrote:
>> In the original OSC spec, pattern matching is used the other way round:
>> handlers have absolute paths, while messages can use wildcard paths, in
>> which case they are dispatched to all matching handlers.
> 
> Actually, I wasn't aware of that (will have to look at the spec again). The 
> code (server.c, dispatch_method) has a check as to whether the path contains 
> a wildcard character:
> 
> 1711:    int pattern = strpbrk(path, " #*,?[]{}") != NULL;
> 
> but it's not clear to me whether this is the path out of the received 
> message or as defined to lo_server_thread_add_method.
> 
> 
> Anyway, is there a better way to do this? I'd like to have one handler that 
> gets all "/channel/*/mixer/audio/*" messages and another that gets 
> "/channel/*/stage/layer/*/*" messages. My workarounds are to either separate 
> them in a single handler or add separate handlers for each message, which 
> seems inefficient.
> 
> Thanks,
> 
> z!
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi,

On 9/28/2015 12:24 PM, Erik Ronström wrote:
> In the original OSC spec, pattern matching is used the other way round:
> handlers have absolute paths, while messages can use wildcard paths, in
> which case they are dispatched to all matching handlers.

Actually, I wasn't aware of that (will have to look at the spec again). The 
code (server.c, dispatch_method) has a check as to whether the path contains 
a wildcard character:

1711:    int pattern = strpbrk(path, " #*,?[]{}") != NULL;

but it's not clear to me whether this is the path out of the received 
message or as defined to lo_server_thread_add_method.


Anyway, is there a better way to do this? I'd like to have one handler that 
gets all "/channel/*/mixer/audio/*" messages and another that gets 
"/channel/*/stage/layer/*/*" messages. My workarounds are to either separate 
them in a single handler or add separate handlers for each message, which 
seems inefficient.

Thanks,

z!

Hi,

In the original OSC spec, pattern matching is used the other way round: handlers have absolute paths, while messages can use wildcard paths, in which case they are dispatched to all matching handlers.

I know there have been discussions about a matching algorithm to do it the other way round, but I don’t know if liblo supports it.

You were probably already aware of this, I just wanted to make sure that this wasn’t the error!

Regards
Erik



> 28 sep 2015 kl. 20:09 skrev Carl z! Zwanzig <zb...@so...>:
> 
> Hi,
> 
> On 9/28/2015 9:15 AM, to...@tr... wrote:
>> it's possible that this relates to the return value of the attached methods.
> 
> Looked at that :). I didn't include all the test code, but the "uncalled" 
> handlers return 0 and the generic handler returns 1. So, in theory, if the 
> generic handler was called first, the specific one should still run, and if 
> the specific one runs first, the generic shouldn't run at all.
> 
> A suspicion is that the handler selection code in server.c is tripping over 
> the data type field, but I haven't studied the code closely. And I could be 
> very wrong on that, too.
> 
> Since I don't have a large set of expected messages, I may code around this 
> and either do my own path matching in a generic handler or only set methods 
> for the complete messages I want. Seems like a bit of a kludge, though.
> 
> Later,
> 
> z!
> 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> liblo-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel

Hi,

On 9/28/2015 9:15 AM, to...@tr... wrote:
> it's possible that this relates to the return value of the attached methods.

Looked at that :). I didn't include all the test code, but the "uncalled" 
handlers return 0 and the generic handler returns 1. So, in theory, if the 
generic handler was called first, the specific one should still run, and if 
the specific one runs first, the generic shouldn't run at all.

A suspicion is that the handler selection code in server.c is tripping over 
the data type field, but I haven't studied the code closely. And I could be 
very wrong on that, too.

Since I don't have a large set of expected messages, I may code around this 
and either do my own path matching in a generic handler or only set methods 
for the complete messages I want. Seems like a bit of a kludge, though.

Later,

z!

Hi,

it's possible that this relates to the return value of the attached methods.

http://liblo.sourceforge.net/docs/lo__types_8h.html#a66faedf5da13231d8c0166870477dce5

"The return value tells the method dispatcher whether this handler has
dealt with the message correctly: a return value of 0 indicates that it
has been handled, and it should not attempt to pass it on to any other
handlers, non-0 means that it has not been handled and the dispatcher will
attempt to find more handlers that match the path and types of the
incoming message."

I'm not sure if the order in which methods are attached is relevant or not.

Best regards
Thomas

On Mon, September 28, 2015 18:04, Carl z! Zwanzig wrote:
> Hello,
>
>
> I'm having some trouble with server methods. For instance, my code says:
>
>
> lo_server_thread_add_method(st, "/channel/*/mixer/audio/*/*", "f",
> mixer_handler, NULL); lo_server_thread_add_method(st, NULL, NULL,
> generic_handler, NULL);
>
> By my reading, only "mixer_handler" should execute for these
> /channel/1/mixer/audio/1/dBFS type=f
> /channel/1/mixer/audio/1/pFS type=f
>
>
> however the only the generic handler is called. I verified that when a
> complete no-wildcard path is used, only that handler is called. I also
> did some experimenting with lo_pattern_match and it appears that the
> patterns themselves work as expected. Is there some specific piece or
> concept that I'm missing? Would be be better just to leave out the generic
> handler?
>
> (using liblo 0.28, built w/ mingw on windoze7)
>
>
> Many thanks,
>
>
> z!
>
> -------------------------------------------------------------------------
> -----
> _______________________________________________
> liblo-devel mailing list lib...@li...
> https://lists.sourceforge.net/lists/listinfo/liblo-devel
>
>

Hello,

I'm having some trouble with server methods. For instance, my code says:

lo_server_thread_add_method(st, "/channel/*/mixer/audio/*/*", "f", 
mixer_handler, NULL);
lo_server_thread_add_method(st, NULL, NULL, generic_handler, NULL);

By my reading, only "mixer_handler" should execute for these
/channel/1/mixer/audio/1/dBFS type=f
/channel/1/mixer/audio/1/pFS type=f

however the only the generic handler is called. I verified that when a 
complete no-wildcard path is used, only that handler is called. I also did 
some experimenting with lo_pattern_match and it appears that the patterns 
themselves work as expected. Is there some specific piece or concept that 
I'm missing? Would be be better just to leave out the generic handler?

(using liblo 0.28, built w/ mingw on windoze7)

Many thanks,

z!

Hi,

I just found what I think is a bug in lo_server_recv_raw_stream_socket. From server.c:

    // If we need more than half the buffer, double the buffer size.
    size = sc->buffer_size;
    if (size < 64)
        size = 64;
    while (buffer_bytes_left < size/2)
    {
        size *= 2;

        // Strictly speaking this is an arbitrary limit and could be
        // removed for TCP, since there is no upper limit on packet
        // size as in UDP, however we leave it for security
        // reasons--an unterminated SLIP stream would consume memory
        // indefinitely.
        if (size > LO_MAX_MSG_SIZE)
           size = LO_MAX_MSG_SIZE;

        buffer_bytes_left = size - sc->buffer_read_offset;
    }

If the condition (size > LO_MAX_MSG_SIZE) is met, the size variable is set to the max message size, but that makes the while condition always match, because buffer_bytes_left will never grows beyond size*2. So the function hangs, repeating the while clause forever.

A solution could be something like

        if (size > LO_MAX_MSG_SIZE) {
           size = LO_MAX_MSG_SIZE;
           buffer_bytes_left = size - sc->buffer_read_offset;
           if (buffer_bytes_left < 0) {
               // Message is bigger than LO_MAX_MSG_SIZE, so return
               // (what about cleanup?)
               return 0;
           }
           break;
        }



Regards
Erik