Propositions for a query system over OSC : Minuit

The Minuit protocol has been designed in order to experiment a communication between the Virage sequencer software and any device or sotfware (like controllers or any media engine, we would call them environment below).

In order to allow users to select the parameter to store, update or observe, Minuit propose some specifications for a query system based on OSC. The protocol is based on four requests to discover an OSC namespace, to get or set values and to be notified when any of them changes.

Structure

Any environment is seen as a namespace of OSC addresses which could also be described as a tree-structure made of nodes, leaves and attributes. Below is an example of how an audio player could be described using this formalism :

Considering the following OSC namespace…

/player/file/path : a string parameter to set the file to read.

/player/file/load : an action to perform in order to open an explorer to select a file on disk.

/player/audio/gain : a decimal parameter to set the volume.

/player/play : a toggle parameter which turn on/off the player.

… here is the equivalent tree structure :

The leaves elements are nodes with a value attribute. They are discriminated from other generic nodes in order to ease the namespace discovery, by offering a shortcut to the value attribute as the value of the leave itself (and thus saving some request bandwidth).

The attribute names are part of the Minuit proposition. They aren’t exhaustive and have to be discussed to take care of what is needed to handle most of parameters / environments specificities. The Minuit specifications also contain a lot of keywords (for type, access, listening, …) that could possibly be replaced by best ones.

Syntax

The Minuit syntax is an important part that describes how a dialog with several environnements could be ensured. Each request could be read like :

Someone asks something at …(data, options)

Or

Someone replies something at …(data, options)

The only exception is when a value is sent to an environment. In that case Minuit uses normal OSC request and the sender is not known. The syntax and the four Minuit requests are fully detailed in the specifications. The example below shows how our audio player (of a Jamoma patch e.g.) could be handled by the Virage Sequencer:

Firstly, Virage asks for namespace discovering of the Jamoma patch :

Virage?namespace / Jamoma:namespace / nodes={ filter player output }

Virage?namespace /player Jamoma:namespace /player nodes={ file audio} leaves={ play } attributes={ comment }

Virage?namespace /player/audio Jamoma:namespace /player/audio leaves={ gain } attributes={ comment priority }

Then, Virage asks some attributes in order to store the state of the player volume …

Virage?get /player/audio/gain (or Virage?get /player/audio/gain:value) Jamoma:get /player/audio/gain 90 (or Jamoma:get /player/audio/gain:value 90)

… or to prepare a mapping :

Virage?namespace /player/audio/gain Jamoma:namespace /player/audio/gain attributes={ value type comment range }

Virage?get /player/audio/gain:type Jamoma:get /player/audio/gain:type decimal

Virage?get /player/audio/gain:range Jamoma:get /player/audio/gain:range 0. 100.

Later the value is recalled by Virage to set the Jamoma player volume :

/player/audio/gain 90

And finally the value of the gain is observed in order to update a view of this parameter :

Virage?listen /player/audio/gain (or Virage?listen /player/audio/gain:value) Jamoma:listen /player/audio/gain 53 (or Jamoma :listen /player/audio/gain:value 53) Jamoma:listen /player/audio/gain 54 Jamoma:listen /player/audio/gain 55 …

In this example it is supposed that Virage knows the IP and PORT of Jamoma and vice-versa. The Minuit query system could be extended by an auto-discovery mechanism (such as of OSC/zeroconf tools) but it hasn’t been implemented yet.