[OSC_dev] OSC address pattern survey

[Andy W. Schmeder]

OSC developers,


To what extent do OSC users/applications/etc use and/or care about the pattern-matching expressions?

More specifically, which of the following matching operators are actually part of common OSC practice?


• '?' 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.




---

Andy W. Schmeder
email: andy [at] cnmat.berkeley.edu
skype: andy.schmeder

Programmer/Analyst II
Research Group
Center for New Music and Audio Technologies
University of California at Berkeley
http://cnmat.berkeley.edu

[s***@xs4all.nl]

Post by Andy W. Schmeder
OSC developers,
To what extent do OSC users/applications/etc use and/or care about the
pattern-matching expressions?
More specifically, which of the following matching operators are actually
part of common OSC practice?
• '?' 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
• 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.
---
Andy W. Schmeder
email: andy [at] cnmat.berkeley.edu
skype: andy.schmeder
Programmer/Analyst II
Research Group
Center for New Music and Audio Technologies
University of California at Berkeley
http://cnmat.berkeley.edu
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

Hi Andy,

I don't use these at all in my own development, and no user has ever
complained about their lack.

I can't really envisage any situations where they would be useful for what
I am doing either.

Salsaman.
http://lives.sourceforge.net

[Tim Thompson]

Post by Andy W. Schmeder
To what extent do OSC users/applications/etc use and/or care about the
pattern-matching expressions?
More specifically, which of the following matching operators are actually
part of common OSC practice?

I've used OSC for a variety of projects, and I've never used any of the
matching operators.

...Tim...

[Mattijs Kneppers]

Hi Andy,

I haven't ran into a situation yet where I needed wildcards, but I can see
the use in theory. Although I would have a hard time predicting which
wildcards I would use or perhaps how far this would end up going towards
full regexp support.

It's funny, this way I see OSC becoming even more of a sort of programming
language. You could almost say that with OSC you're defining a standard for
cross-platform, cross-device APIs.

Best,
Mattijs

Post by Andy W. Schmeder
To what extent do OSC users/applications/etc use and/or care about the

Post by Andy W. Schmeder
pattern-matching expressions?
More specifically, which of the following matching operators are actually
part of common OSC practice?

I've used OSC for a variety of projects, and I've never used any of the
matching operators.

[Théo de la Hogue]

Hi everybody,
I'm involved into the Jamoma project which proposed, among other things, a syntax to structure a Max patchers into sharable modules.
Any jamoma parameter is registered into a tree structure following the OSC address pattern style.
So, even if it's still not possible in the 0.5 version, we plan to be able to handle the '*' and the "{foo, bar}" to address all or a set of parameter instances.

For example those features are expected for spatialisation parameters control where many sources and speakers have to be handled. It could provided an easier way deal with multiple instances by sending some messages like /source.*/position 0. 0. 0. for an initialisation process or /speaker.{1, 3, 5}/gain 0.3 to control in one message the left side of a surround system (as you can notice, the '.' is used to precise the instance part which is not very OSC compliant but very usefull for parsing !)

However it seems that those features need to be handled on the software side because only the software is able to replace a '*' by all of the existing instances and then route the message to each parameter. That why we're working on a framework to make those features easier to integrate in any software (not only in Max I mean). Even if it's still an experimental work, I'll be very happy to share our results on this point.

Cheers
--
Théo de la Hogue
Chargé de la recherche et de la formation

GMEA – Centre National de création Musicale d’Albi-Tarn
4 rue Sainte Claire – 81000 ALBI
tel: [phone]
fax: [phone]
***@wanadoo.fr
www.gmea.net

Post by Andy W. Schmeder
OSC developers,
To what extent do OSC users/applications/etc use and/or care about the pattern-matching expressions?
More specifically, which of the following matching operators are actually part of common OSC practice?
• '?' in the OSC Address Pattern matches any single character
• '*' in the OSC Address Pattern matches any sequence of zero or more characters
• 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.
---
Andy W. Schmeder
email: andy [at] cnmat.berkeley.edu
skype: andy.schmeder
Programmer/Analyst II
Research Group
Center for New Music and Audio Technologies
University of California at Berkeley
http://cnmat.berkeley.edu
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev

[Adrian Freed]

Post by Théo de la Hogue
Hi everybody,
I'm involved into the Jamoma project which proposed, among other things, a syntax to structure a Max patchers into sharable modules.
Any jamoma parameter is registered into a tree structure following the OSC address pattern style.
So, even if it's still not possible in the 0.5 version, we plan to be able to handle the '*' and the "{foo, bar}" to address all or a set of parameter instances.
For example those features are expected for spatialisation parameters control where many sources and speakers have to be handled. It could provided an easier way deal with multiple instances by sending some messages like /source.*/position 0. 0. 0. for an initialisation process or /speaker.{1, 3, 5}/gain 0.3 to control in one message the left side of a surround system (as you can notice, the '.' is used to precise the instance part which is not very OSC compliant but very usefull for parsing !)

Thanks Theo.
The use of "." in Jamoma is not inconsistent with OSC goals in general. The idea of the address space is that is designed for the application by the users and it isn't necessary
to use a hierarchical name space as implied but not required by the "/" symbol. It is easy to design a name space that is like the named attributes of databases and HTTP GET requests, for example.
As we clarify and "modernise" the 1.0 specification we will try to emphasize these diverse uses of OSC names which were designed and documented in an the era of hierarchical file systems by us folk also familiar with more general models, e.g. Lisp property lists.

[Pedro Lopes]

[Théo de la Hogue]

Thanks Adrian for bringing the light on the OSC approach about address space.
I pay attention on this thread.

best,
Théo

Post by Adrian Freed

Post by Théo de la Hogue
Hi everybody,
I'm involved into the Jamoma project which proposed, among other things, a syntax to structure a Max patchers into sharable modules.
Any jamoma parameter is registered into a tree structure following the OSC address pattern style.
So, even if it's still not possible in the 0.5 version, we plan to be able to handle the '*' and the "{foo, bar}" to address all or a set of parameter instances.
For example those features are expected for spatialisation parameters control where many sources and speakers have to be handled. It could provided an easier way deal with multiple instances by sending some messages like /source.*/position 0. 0. 0. for an initialisation process or /speaker.{1, 3, 5}/gain 0.3 to control in one message the left side of a surround system (as you can notice, the '.' is used to precise the instance part which is not very OSC compliant but very usefull for parsing !)

Thanks Theo.
The use of "." in Jamoma is not inconsistent with OSC goals in general. The idea of the address space is that is designed for the application by the users and it isn't necessary
to use a hierarchical name space as implied but not required by the "/" symbol. It is easy to design a name space that is like the named attributes of databases and HTTP GET requests, for example.
As we clarify and "modernise" the 1.0 specification we will try to emphasize these diverse uses of OSC names which were designed and documented in an the era of hierarchical file systems by us folk also familiar with more general models, e.g. Lisp property lists.
_______________________________________________
OSC_dev mailing list
http://lists.create.ucsb.edu/mailman/listinfo/osc_dev