liblo-devel Mailing List for LibLO

On 9 Apr 2009, at 18:51, Stephen Sinclair wrote:
>>> Yes, I agree that it's a big annoying to get information from the
>>> 'path' by using sscanf or whatnot.  I've said before that I don't
>>> really like having to use regexps for example on OSC paths, since  
>>> it's
>>> sort of re-implementing the pattern matching all over again.  I  
>>> prefer
>>> the idea of using the pattern matching as it's supposed to and, yes,
>>> having the function be called once for each match.
>>
>> But you don't have to do that, that's the idea of the (void *)i bit.
>> Obviously it would be a bit nicer if it was a pointer to a struct or
>> similar, but it makes the point.
>
> Of course.  I wonder though, if it might useful to provide char*
> pointers into the path at each '/' so that this info can be extracted
> really easily without having to do much string manipulation.

I guess it might be useful as a utility function of some sort.

>>> Obviously I can see that it's not particularly optimized to do so.
>>> Maybe for these instances you could just define an 'all' handler  
>>> which
>>> knows how to deal with the lights as a group?
>>>
>>> /dmx/all/set 0.0
>>
>> You could also have a "matches everything" pattern (NULL IIRC), which
>> looked out for the special case of /dmx/*/set n and handled it more
>> efficiently. For 512 channels it doesn't seem necessary though.
>
> There's been a couple of posts before on this list about wanting to
> create patterned message handlers.  I posted a patch that enables it,
> though didn't include it in liblo since it was a bit inefficient.
>
> However that was a bit different than having a handler for a specific
> incoming pattern.  Might be useful and interesting if only to allow
> people to achieve better efficiency should they so chose, by
> "overloading" the standard pattern matching behaviour.

Yes. It might give people a false impression of exactly what it was  
doing though.

- Steve

On Thu, Apr 9, 2009 at 5:18 AM, Steve Harris <S.W...@ec...> wrote:
> Trying again...
>
> On 8 Apr 2009, at 17:48, Stephen Sinclair wrote:
>>>>>> 1) Synthesise a route for every channel at start, eg:
>>>>>> for(i=0;i<512;i++) {
>>>>>>  lo_server_thread_add_method....
>>>>>> }
>>>>>
>>>>> That's what I had in mind. There's some user data that lets you
>>>>> pass that
>>>>> channel number it's bound to in the method call. Like:
>>>>> lo_server_thread_add_method(st, path, "f", h, (void *)i);
>>>>> [with apologies for the ugly cast]
>>>
>>> I implemented this after I sent the email and it turns out that
>>> 'path'
>>> is the path that was matched in the routing table, not the path from
>>> the message. So you can use sscanf to get the channel number :-)
>>
>> Yes, I agree that it's a big annoying to get information from the
>> 'path' by using sscanf or whatnot.  I've said before that I don't
>> really like having to use regexps for example on OSC paths, since it's
>> sort of re-implementing the pattern matching all over again.  I prefer
>> the idea of using the pattern matching as it's supposed to and, yes,
>> having the function be called once for each match.
>
> But you don't have to do that, that's the idea of the (void *)i bit.
> Obviously it would be a bit nicer if it was a pointer to a struct or
> similar, but it makes the point.

Of course.  I wonder though, if it might useful to provide char*
pointers into the path at each '/' so that this info can be extracted
really easily without having to do much string manipulation.

>> Obviously I can see that it's not particularly optimized to do so.
>> Maybe for these instances you could just define an 'all' handler which
>> knows how to deal with the lights as a group?
>>
>> /dmx/all/set 0.0
>
> You could also have a "matches everything" pattern (NULL IIRC), which
> looked out for the special case of /dmx/*/set n and handled it more
> efficiently. For 512 channels it doesn't seem necessary though.

There's been a couple of posts before on this list about wanting to
create patterned message handlers.  I posted a patch that enables it,
though didn't include it in liblo since it was a bit inefficient.

However that was a bit different than having a handler for a specific
incoming pattern.  Might be useful and interesting if only to allow
people to achieve better efficiency should they so chose, by
"overloading" the standard pattern matching behaviour.


> Adding a .../all/... might confuse external clients and makes the
> behaviour of /dmx/*/set a bit odd (does it send the 0.0 over DMX
> twice?, once? etc.)
>
> Incidentally, I met Nick in the pub last night, he and Yves have been
> doing some cool stuff with this DMX interface.

Nice!  Would love to see a video.


Steve

Trying again...

On 8 Apr 2009, at 17:48, Stephen Sinclair wrote:
>>>>> 1) Synthesise a route for every channel at start, eg:
>>>>> for(i=0;i<512;i++) {
>>>>>  lo_server_thread_add_method....
>>>>> }
>>>>
>>>> That's what I had in mind. There's some user data that lets you
>>>> pass that
>>>> channel number it's bound to in the method call. Like:
>>>> lo_server_thread_add_method(st, path, "f", h, (void *)i);
>>>> [with apologies for the ugly cast]
>>
>> I implemented this after I sent the email and it turns out that  
>> 'path'
>> is the path that was matched in the routing table, not the path from
>> the message. So you can use sscanf to get the channel number :-)
>
> Yes, I agree that it's a big annoying to get information from the
> 'path' by using sscanf or whatnot.  I've said before that I don't
> really like having to use regexps for example on OSC paths, since it's
> sort of re-implementing the pattern matching all over again.  I prefer
> the idea of using the pattern matching as it's supposed to and, yes,
> having the function be called once for each match.

But you don't have to do that, that's the idea of the (void *)i bit.  
Obviously it would be a bit nicer if it was a pointer to a struct or  
similar, but it makes the point.

> Obviously I can see that it's not particularly optimized to do so.
> Maybe for these instances you could just define an 'all' handler which
> knows how to deal with the lights as a group?
>
> /dmx/all/set 0.0

You could also have a "matches everything" pattern (NULL IIRC), which  
looked out for the special case of /dmx/*/set n and handled it more  
efficiently. For 512 channels it doesn't seem necessary though.

Adding a .../all/... might confuse external clients and makes the  
behaviour of /dmx/*/set a bit odd (does it send the 0.0 over DMX  
twice?, once? etc.)

Incidentally, I met Nick in the pub last night, he and Yves have been  
doing some cool stuff with this DMX interface.

- Steve

On Mon, Apr 6, 2009 at 6:05 PM, Nicholas J Humfrey <nj...@ae...> wrote:
>
>
>> From: Steve Harris <st...@pl...>
>> Date: Sun, 5 Apr 2009 18:54:56 +0100
>> Subject: Fwd: [liblo] Pattern matching
>>
>> Hi Nick,
>>
>> I forgot what email address I signed up to the liblo list with, so
>> resending
>> direct.
>>
>> - Steve
>>
>> Begin forwarded message:
>>
>>> From: lib...@li...
>>> Date: 5 April 2009 18:45:03 BST
>>> To: sw...@ec...
>>> Subject: Re: [liblo] Pattern matching
>>>
>>>
>>> You are not allowed to post to this mailing list, and your message
>>> has
>>> been automatically rejected.  If you think that your messages are
>>> being rejected in error, contact the mailing list owner at
>>> lib...@li....
>>>
>>>
>>> From: Steve Harris <sw...@ec...>
>>> Date: 5 April 2009 18:44:49 BST
>>> To: liblo development list <lib...@li...>
>>> Subject: Re: [liblo] Pattern matching
>>>
>>>
>>> On 5 Apr 2009, at 12:36, Nicholas J Humfrey wrote:
>>>
>>>> Hello,
>>>>
>>>> I am working on an OSC -> DMX (lighting protocol) server using
>>>> libusb
>>>> and liblo. The DMX protocol gives you 512 channels which each can be
>>>> set to a value between 0 and 255.
>>>>
>>>> I previously emailed the OSC_dev mailing list and Adrian replied
>>>> suggesting that I use the following format:
>>>>
>>>> /dmx/<channel>/set f <value>
>>>
>>> Hi Nick,
>>>
>>> Why the 'set' verb, out of interest? Looks a bit like the ugly OO
>>> fallback of
>>> foo.setBar(n).
>>> I'd have thought
>>>   /dmx/<channel> f <value>
>>> was sufficient, with
>>>   /dmx/<channel>
>>> if you want to get the value. It's more RESTful, at least.
>
> The reasoning was that I was considering having other methods such as
> 'fade' - so 'set' was to change the channel directly to a specific
> value. But I agree that RESTful is more desirable.
>
> I was also thinking about:
> /dmx/<channel>/off
> /dmx/<channel>/on
>
> Adrian suggested using Timetags for fades, I'm not sure exactly how
> that would work.
>
>
>>>> Where value is a number between 0 and 1, representing the
>>>> brightness.
>>>> The reason for having the channel number in the path is that it
>>>> allows
>>>> you to turn all the lights on or off:
>>>>
>>>> /dmx/*/set 0.0
>>>>
>>>>
>>>> But how is the best way to achieve this in liblo? I can think of two
>>>> possible solutions, but I'm not sure what is best.
>>>>
>>>>
>>>> 1) Synthesise a route for every channel at start, eg:
>>>> for(i=0;i<512;i++) {
>>>>   lo_server_thread_add_method....
>>>> }
>>>
>>> That's what I had in mind. There's some user data that lets you
>>> pass that
>>> channel number it's bound to in the method call. Like:
>>>  lo_server_thread_add_method(st, path, "f", h, (void *)i);
>>> [with apologies for the ugly cast]
>
> I implemented this after I sent the email and it turns out that 'path'
> is the path that was matched in the routing table, not the path from
> the message. So you can use sscanf to get the channel number :-)

Yes, I agree that it's a big annoying to get information from the
'path' by using sscanf or whatnot.  I've said before that I don't
really like having to use regexps for example on OSC paths, since it's
sort of re-implementing the pattern matching all over again.  I prefer
the idea of using the pattern matching as it's supposed to and, yes,
having the function be called once for each match.

Obviously I can see that it's not particularly optimized to do so.
Maybe for these instances you could just define an 'all' handler which
knows how to deal with the lights as a group?

/dmx/all/set 0.0

The advantage for me of being able to use pattern matching is more
than just simple * matching for all lights.  You can also do nifty
things like target specific lights:

/dmx/{29,62}/set 0.0

Additionally, you can dynamically add and remove handlers for specific
lights when for example they are plugged in or out of the lighting
rig.  That way the system would "know" exactly which handlers to call,
instead of blindly sending out 512 DMX messages assuming they are all
plugged in.


>>> Given how slow DMX and USB are, 512 function calls is not really an
>>> issue
>>> IMHO.
>
> Agreed.

Yeah, I'd be more worried if it a few orders of magnitude higher, but
512 function calls isn't _really_ a big deal.

Steve

> From: Steve Harris <st...@pl...>
> Date: Sun, 5 Apr 2009 18:54:56 +0100
> Subject: Fwd: [liblo] Pattern matching
>
> Hi Nick,
>
> I forgot what email address I signed up to the liblo list with, so  
> resending
> direct.
>
> - Steve
>
> Begin forwarded message:
>
>> From: lib...@li...
>> Date: 5 April 2009 18:45:03 BST
>> To: sw...@ec...
>> Subject: Re: [liblo] Pattern matching
>>
>>
>> You are not allowed to post to this mailing list, and your message  
>> has
>> been automatically rejected.  If you think that your messages are
>> being rejected in error, contact the mailing list owner at
>> lib...@li....
>>
>>
>> From: Steve Harris <sw...@ec...>
>> Date: 5 April 2009 18:44:49 BST
>> To: liblo development list <lib...@li...>
>> Subject: Re: [liblo] Pattern matching
>>
>>
>> On 5 Apr 2009, at 12:36, Nicholas J Humfrey wrote:
>>
>>> Hello,
>>>
>>> I am working on an OSC -> DMX (lighting protocol) server using  
>>> libusb
>>> and liblo. The DMX protocol gives you 512 channels which each can be
>>> set to a value between 0 and 255.
>>>
>>> I previously emailed the OSC_dev mailing list and Adrian replied
>>> suggesting that I use the following format:
>>>
>>> /dmx/<channel>/set f <value>
>>
>> Hi Nick,
>>
>> Why the 'set' verb, out of interest? Looks a bit like the ugly OO  
>> fallback of
>> foo.setBar(n).
>> I'd have thought
>>   /dmx/<channel> f <value>
>> was sufficient, with
>>   /dmx/<channel>
>> if you want to get the value. It's more RESTful, at least.

The reasoning was that I was considering having other methods such as  
'fade' - so 'set' was to change the channel directly to a specific  
value. But I agree that RESTful is more desirable.

I was also thinking about:
/dmx/<channel>/off
/dmx/<channel>/on

Adrian suggested using Timetags for fades, I'm not sure exactly how  
that would work.


>>> Where value is a number between 0 and 1, representing the  
>>> brightness.
>>> The reason for having the channel number in the path is that it  
>>> allows
>>> you to turn all the lights on or off:
>>>
>>> /dmx/*/set 0.0
>>>
>>>
>>> But how is the best way to achieve this in liblo? I can think of two
>>> possible solutions, but I'm not sure what is best.
>>>
>>>
>>> 1) Synthesise a route for every channel at start, eg:
>>> for(i=0;i<512;i++) {
>>>   lo_server_thread_add_method....
>>> }
>>
>> That's what I had in mind. There's some user data that lets you  
>> pass that
>> channel number it's bound to in the method call. Like:
>>  lo_server_thread_add_method(st, path, "f", h, (void *)i);
>> [with apologies for the ugly cast]

I implemented this after I sent the email and it turns out that 'path'  
is the path that was matched in the routing table, not the path from  
the message. So you can use sscanf to get the channel number :-)


>> Given how slow DMX and USB are, 512 function calls is not really an  
>> issue
>> IMHO.

Agreed.


>>> Liblo would then be able to deal with the pattern matching itself  
>>> and
>>> for the '/dmx/*/set' example it would call my method 512 times.
>>
>> Yup.
>>


Video of LED lamp controlled by OSC:
http://www.aelius.com/njh/tmp/rgb_ramp.mov
http://www.aelius.com/njh/tmp/rgb_ramp.rb.txt


nick.

Hello,

I am working on an OSC -> DMX (lighting protocol) server using libusb  
and liblo. The DMX protocol gives you 512 channels which each can be  
set to a value between 0 and 255.

I previously emailed the OSC_dev mailing list and Adrian replied  
suggesting that I use the following format:

/dmx/<channel>/set f <value>

Where value is a number between 0 and 1, representing the brightness.  
The reason for having the channel number in the path is that it allows  
you to turn all the lights on or off:

/dmx/*/set 0.0


But how is the best way to achieve this in liblo? I can think of two  
possible solutions, but I'm not sure what is best.


1) Synthesise a route for every channel at start, eg:
for(i=0;i<512;i++) {
    lo_server_thread_add_method....
}

Liblo would then be able to deal with the pattern matching itself and  
for the '/dmx/*/set' example it would call my method 512 times.

2) have a single wildcard method that matches every message and then  
have to deal with the pattern matching myself. I probably wouldn't  
implement it the OSC spec properly, but I could optimise the '/dmx/*/ 
set' example to be more efficient.


Any suggestions? Anyone done anything like this already?



nick.