Page 1 of 1

Lemur not fully OSC compliant yet: Address Pattern Matching

Posted: 04 Apr 2015 23:18
by Voice303
The Lemur manual says Lemur is fully OSC compliant in section 2.8: "Lemur is compliant with the Open Sound Control protocol". Unfortunately in the current state of Lemur this is simply a half truth at best. According to the 1.0 version of the OSC specification this should be implemented: http://opensoundcontrol.org/spec-1_0 "OSC Message Dispatching and Pattern Matching". There is no way in Lemur to do anything described in that part of the OSC specification.

For instance, the template I am working on needs to implement the following OSC addresses:

/track/X/clip/X/hasContent

Where X is 1-8 for both track and clip. If you do the math thats 64 addresses I need to implement just to interface ONE type of message without pattern matching.

What I propose it to be able to implement the following address:

/track/*/clip/*/hasContent

From there I would like to access what the wildcard filled in like so:

OSC_ADDRESSMATCH[X]

According to the OSC specification the following should be supported and exposed to the scripting interface before one could say Lemur is indeed OSC compliant

'?' in the OSC Address Pattern matches any single character
'*' in the OSC Address Pattern matches any sequence of zero or more characters
A string of characters in square brackets (e.g., "[string]") in the OSC Address Pattern matches any character in the string. Inside square brackets, the minus sign (-) and exclamation point (!) have special meanings:
two characters separated by a minus sign indicate the range of characters between the given two in ASCII collating sequence. (A minus sign at the end of the string has no special meaning.)
An exclamation point at the beginning of a bracketed string negates the sense of the list, meaning that the list matches any character not in the list. (An exclamation point anywhere besides the first character after the open bracket has no special meaning.)
A comma-separated list of strings enclosed in curly braces (e.g., "{foo,bar}") in the OSC Address Pattern matches any of the strings in the list.
Any other character in an OSC Address Pattern can match only the same character.

Voice303

Re: Lemur not fully OSC Compliant yet: Address Pattern Match

Posted: 06 Apr 2015 21:18
by Suloo
yes, this would be really awesome and helpful to reduce the clutter. Also better to maintain the objects.

thx for the suggestion voice303!

Re: Lemur not fully OSC compliant yet: Address Pattern Match

Posted: 14 Apr 2015 16:12
by Voice303
Another part of Lemur that is not OSC compliant: no support for OSC message types that do not have a value in the data section (such as boolean)

Re: Lemur not fully OSC compliant yet: Address Pattern Match

Posted: 15 Apr 2015 01:17
by Macciza
Yep, I raised pattern matching with them a while ago, will see what I can find out
Quite a few Libs only do OSC v1.0 where such tags as T, F, I etc are optional
They are in the 1.1 spec though and that should probably be the current benchmark ...

There are also a number of implementation issues in how Lemur could return the pattern matched data
You need to identify each address with the attached data, and do further matching in the script . . .
it would be good to improve the OSC implementation further . . .

Re: Lemur not fully OSC compliant yet: Address Pattern Match

Posted: 15 Apr 2015 06:38
by Suloo
Yea, hopefully this will come in the future! :)

Re: Lemur not fully OSC compliant yet: Address Pattern Match

Posted: 23 Jun 2016 04:50
by Gluon
+1 to what was said above but also implement address pattern matching wildcard from OSC 1.1 spec i.e. //
Please consider this.

Thank you.