Lemur not fully OSC compliant yet: Address Pattern Matching
Posted: 04 Apr 2015 23:18
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
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