What if you want your OSC method to respond to more than one "TYPE" of OSC value?

[mrRay]

The above proposal is based on the assumption that OSC methods will only have a single "TYPE" of value- in other words, each OSC method will only respond to OSC messages with a single, specific type tag string. This is convenient and simple, but it might also be nice if OSC methods could respond to OSC messages with several different type tag strings (it might be nice if an OSC method could respond to either an "int" or a "float" message, for example). The following alternate "TYPE" and "VAL" query definitions explore this notation- I'm not sure if the additional functionality is worth the additional complexity, and would like some feedback from other people: do you think we should keep things simple, or do you think we should consider using this alternate query type?

• ALTERNATE "TYPE" QUERY A reply to a TYPE query will contain a number of OSC strings- each of these OSC strings is a type tag string describing the types of value/values that can be retrieved from or sent to this method. Most OSC methods will only have a single value type ("float", or "int", etc)- while this is convenient (and probably the most common) use, a significant number of existing OSC implementations work with ad-hoc data types consisting of an OSC array with multiple values, or even just OSC messages with more than one value. It would also be nice if OSC methods could respond to different types of OSC values (an OSC method for setting the value of a pop-up menu could respond to either integer values for choosing by index, or a string value for choosing by name). The TYPE query is capable of describing all of these, as demonstrated with the following examples: OSC Method that returns/expects a single float value

->  /foo/bar/methodName1#TYPE
<-  /foo/bar/methodName1##TYPE s : "f"

OSC Method that returns/expects two float values (not an array, just two float values in the OSC message)

->  /foo/bar/methodName2#TYPE
<-  /foo/bar/methodName2##TYPE  s : "ff"

OSC Method that returns/expects two values as an array

->  /foo/bar/methodName3#TYPE
<-  /foo/bar/methodName3##TYPE  s : "[ff]"

OSC Method that returns/expects either an int or a float

->  /foo/bar/methodName4#TYPE
<-  /foo/bar/methodName4##TYPE  ss : "i" "f"

OSC Method that returns/expects either an int or a symbol

->  /foo/bar/methodName5#TYPE
<-  /foo/bar/methodName5##TYPE  ss : "i" "s"

OSC Method that returns/expects either an int or two floats

->  /foo/bar/methodName6#TYPE
<-  /foo/bar/methodName6##TYPE  ss : "i" "ff"

OSC Method that returns/expects either an int or an array with two floats

->  /foo/bar/methodName7#TYPE
<-  /foo/bar/methodName7##TYPE  ss : "i" "[ff]"

• ALTERNATE "VAL" QUERY The VAL query is the only type of query message that should ever have a value with it. The value in your query message should be an OSC string which contains the type tag string of the value/values you'd like to receive in reply to your query. This value is optional: if your VAL query doesn't include a type tag string and the OSC method is capable of responding to multiple types, its reply will have the first type tag string returned by a TYPE query. If your VAL query requests a type tag string which is unsupported by the destination OSC method, the server should return a 406 error. OSC Method that returns/expects a single float value

->  /foo/bar/methodName1#VAL
<-  /foo/bar/methodName1##VAL f : 1.0

OSC Method that returns/expects two float values (not an array, just two float values in the OSC message)

->  /foo/bar/methodName2#VAL
<-  /foo/bar/methodName2##VAL ff : 1.0 1.0

OSC Method that returns/expects two values as an array

->  /foo/bar/methodName3#VAL
<-  /foo/bar/methodName3##VAL [ff] : 1.0 1.0

OSC Method that returns/expects either an int or a float

->  /foo/bar/methodName4#VAL
<-  /foo/bar/methodName4##VAL i : 1
->  /foo/bar/methodName4#VAL  s : "i"
<-  /foo/bar/methodName4##VAL i : 1
->  /foo/bar/methodName4#VAL  s : "f"
<-  /foo/bar/methodName4##VAL f : 1.0

OSC Method that returns/expects either an int or a symbol

->  /foo/bar/methodName5#VAL
<-  /foo/bar/methodName5##VAL i : 1
->  /foo/bar/methodName5#VAL  s : "i"
<-  /foo/bar/methodName5##VAL i : 1
->  /foo/bar/methodName5#VAL  s : "s"
<-  /foo/bar/methodName5##VAL s : "one"

OSC Method that returns/expects either an int or two floats

->  /foo/bar/methodName6#VAL
<-  /foo/bar/methodName6##VAL i : 1
->  /foo/bar/methodName6#VAL  s : "i"
<-  /foo/bar/methodName6##VAL i : 1
->  /foo/bar/methodName6#VAL  s : "ff"
<-  /foo/bar/methodName6##VAL ff : 1.0 1.0

OSC Method that returns/expects either an int or an array with two floats

->  /foo/bar/methodName7#VAL
<-  /foo/bar/methodName7##VAL i : 1
->  /foo/bar/methodName7#VAL  s : "i"
<-  /foo/bar/methodName7##VAL i : 1
->  /foo/bar/methodName7#VAL  s : "[ff]"
<-  /foo/bar/methodName7##VAL [ff] : 1.0 1.0

[lov]

no, I don’t see we really need this, better to keep things simple

[bltzr]

:+1: for keeping things simple, at least in a first version

[theod]

maybe a stupid question : if we use a json or xml format to describe the namespace, is it not better to share TYPE, RANGE, ACCESS and any other OSCMethod or OSCContainer informations into the description ?

this will reduce the number of queries to only keep CONTENTS and VAL (and I would rename them into DESCRIPTION and VALUE in the same time :-)

but I'm maybe too radical and I miss something obvious !

This proposition also allows to simply load a json description of an OSC application if it is not able to describe them self which is particularly useful for a software where the OSCQuery proposal cannot be added by our self (e.g Modul8, DLigth, …) or for an application embedded into a small device where the OSCQuery proposal cannot be implemented like an arduino ...

[theod]

and this proposition is related to https://github.com/mrRay/OSCQueryProposal/issues/5 issue