New Types we Need:

Vector of n-things the same type (OSW and others)

For this I propose a template syntax, here implemented using (). Similar to blob it must encode the total number of multiple of that type.

Example 1: Some number of floats:

(f)

Note that we don’t consider () to be a tuple (that is provided by []). Thus the following are equivalent:

fff

(f) 3 …

For a vector we recommend encapsulating in []:

[(f)]

Example 2: Repeating templates: some number of pairs of string, float tuples.

(sf)

Dictionary (SuperCollider) aka options list, tree structure, graph

These are useful for specification of complex parameters. Defaults are specified though graph compositing which allows great specificity, inheritance. In general it is an ontology so we should future-proof it and allow for predicated connections.

Example 1: Key-value specification (predicate = default or none).

[{sf}{sf}{sf}] “frequency”, 440.0, “phase”, 0.0, “scale”, “1.0”

Example 2:

Combine with () for a static allocated dictionary of arbitrary size:

[({sf})] 3 “frequency”, 440.0, …

Example 3: RDF triples, just use three items instead of two.

[{ssf}] “osc::version”, “osc::version-exceeds”, 1.0f

A mime-typed binary section (Ventuz, OSW “classes”, etc)

Sometimes people are tempted to invent OSC type-tags for ever more esoteric media types, such as image. This can be better achieved by allowing the protocol to encapsulate a mime-encoded binary section. There are thousands of registered mime types. Recommend the capital B for the mime-typed blob, which is encoded as content-type string + blob length + blob. (_b ?)

Unicode string (see Ventuz OSC.NET)

Implications of this type may be somewhat complicated. There are several forms of unicode. Furthermore there is the issue of making the address space of OSC also open to alternative text-encodings. This would make OSC fully international. Research pending.

Complex float (OSW)

Complex double precision (OSW)

This mathematical abstraction is sufficiently common to warrant a core type tag.

More experimental but to consider:

Arrays of types smaller than 32 bits: 16, 8, 1. (OSW and others?)

Would this satisfy the request for a “bit-field”? This would be extremely compact for low-bit interfaces.

Rational fixed point numbers, e.g. 32.32, 16.16.

Even faster than fixed-point float conversion, but very special-case-ish.