Suggestions drawing from a NIME article on OSC-Namespaces

[onar3d]

Hi!

I've been developing an OSC-centric software application for quite some time now, that I am soon to release (www.thewizardofosc.com). For serialization and state management in that, I defined two schemata, one for defining an OSC-Namespace, and one for an OSC-State. Much of what goes into defining these schemata is very similar to the work I only just now discovered has been going on here!

From my experience with the above software, I have a few suggestions/discussion points that may be interesting to discuss here - they are all drawn from this article: http://www.nime.org/proceedings/2014/nime2014_300.pdf

I find that another very useful optional attribute is "Continuity":

• "Continuity” (Discreet, Continuous): states if the message is to be interpreted as an event or not. For example, a button press message is a new event, even if it has the same value as the previous button press message, and is thus labelled Discreet. A message communicating the output sound volume level however, only makes sense as an event if the value to be sent is different from the previous one, thus labelled Continuous.

And, per TypeTag:

• A description/ID for the TypeTag: very often OSC is abused (se TUIO), meaning there are lists of many TT's, sometimes more than 10. A way of identifying what each is then becomes very important.
• “Default” holds a default value for the TT.
• “Trigger” (1, 0): should a new value set to the type-tag, result in an entire new message being triggered? Usually only one of the values should be set to trigger, leftmost or rightmost, depending on whether the list of parameters should be treated left to right, or right to left (Pure Data style or Max/MSP style).

Of course, given the many values per TT, as you'll see int the article I'm quite partial to the organization of having all attributes that correspond to a TT in a dedicated named node, under a parent TTS node, instead of in a series of arrays.

• Functionally the two solutions seem to me to be the same at first thought. But, it is frequent that some TT's have attributes that others do not (e.g. ranges). With the list solution, that will result in many null entries in lists.
• And, having a named node per TT also forces developers to name TT's, which can be a good thing or a bad thing depending on the average length of the TypeTagStrings in the given namespace.
• It also allows for a message allowing for more than one TTS - which I am not sure the list solution allows for as easily.

What do you think on the above?

Best, Ilias B.

[jcelerier]

A description/ID for the TypeTag: very often OSC is abused (se TUIO), meaning there are lists of many TT's, sometimes more than 10. A way of identifying what each is then becomes very important.

Do you have an example of the need to give a programmatic description for each of the attribute ? (I guess if you want to pass some arrays of objects, maybe ?)

I would be for adding an optional (please don't beat me :) ) attribute "USER_TYPE" (or maybe "EXTENDED_TYPE" ?) with the following spec :

• The attribute's value can be a string with a meaningful semantic information. For instance, if you are sending a string corresponding to a filepath in OSC, you could have "EXTENDED_TYPE": "filepath" which would allow the other software to show a file chooser instead of just a line edit.

• Or, the attribute's value can be an array, in which case every element of the array (recursively) has to be a string that gives a semantic description of each element in the type tag :

  "TYPE": "i[ff]s", "EXTENDED_TYPE": [ "identifier", [ null, null ], "filepath" ]

Could you give a list of what kind of identification would be necessary for you ? Passing an identifier (for instance like in Ableton's live osc API which passes the id of the track as first OSC argument) seems quite common, there is also the filepath thing, but I cannot think of others right now.

“Default” holds a default value for the TT.

+1 for this, I already have a "DEFAULT_VALUE" implemented in libossia.

"Continuity” (Discreet, Continuous): states if the message is to be interpreted as an event or not. For example, a button press message is a new event, even if it has the same value as the previous button press message, and is thus labelled Discreet. A message communicating the output sound volume level however, only makes sense as an event if the value to be sent is different from the previous one, thus labelled Continuous.

+1 for this, there is a similar attribute in libossia : "REPETITION_FILTER": (true|false) which indicates if a subsequent message with the same value should be filtered.

[onar3d]

Hi!

On TT ID: The reason is purely for the sake of end users: OSC is fantastic because it is human readable. But, a list of 10 values with nothing identifying them besides their common address pattern is obtuse. A String ID with a name which humans can make sense of alleviates this, and keeps OSC human readable.

If you look at a Mapping Matrix in the AudioVisualBach example in The Wizard of OSC from the link above, you will see an example where an OSC message with typetag 'ii', AP /Synth1/Note, also has the extra description "Note" for the first 'i' and "Vel' for the second. Having those means the user can map these values with a clear understanding of what they represent.

I would not conflate this ID with optional attributes that are interpreted by the transmitting/receiving software. But, I am all for such attributes of course, although the more they are, the less likely all OSC-capable software is to support them :)

[jcelerier]

indeed, midi notes are a good idea !

I would not conflate this ID with optional attributes that are interpreted by the transmitting/receiving software. But, I am all for such attributes of course, although the more they are, the less likely all OSC-capable software is to support them :)

My personal opinion is that for hints and concepts that are sufficiently used in existing software (and I'd say that midi note information is part of this) it can be very useful to provide a "standardised" name for the information.

The LV2 people have done a lot of work on this (http://lv2plug.in/ns/ and for instance this : http://lv2plug.in/doc/html/group__atom.html or this : http://lv2plug.in/doc/html/group__midi.html ), that could maybe be leveraged ?

Basically, the more things people can get to agree on, the better for everyone who wants to make a new software. And of course, this should be entirely optional, just like the OSC spec states "any unknown attribute can be ignored by the software".