[LV2] Mapping of OSC to LV2 Atoms

[David Robillard]

On Fri, 2015-06-19 at 22:33 +0200, Hanspeter Portner wrote:
> Potential Issues
> ================
> 
> * The OSC bundle timestamp and timestamp type 't' must be cast
>   from unsigned to signed as there are no usigned atoms.

Unfortunate, but maybe an atom type for specifically this sort of
timestamp wouldn't be a bad idea.  Though the time stamps don't seem
particularly useful in this context, to me.

> I actually only care for the base and extended types but
> it may make sense to include the exotic types too for
> the sake of completeness.
> 
> * The four exotic OSC types 'T'rue, 'F'alse, 'N'il, 'I'nfinitum have
>   no associated data in OSC. Should they be mapped to atoms and
>   packed into the arguments tuple or only show up in the message
>   format string like in OSC?

I don't know about nil and infinitum, but it seems true and false
clearly map to Bool.  There is no type string for atom objects, so a
true bidirectional mapping shouldn't be missing bits and rely on some
external funny thing (a format string) to fill in the gaps, IMO.

> * Even more exotic types 'c'har, 'S'ymbol and 'm'idi are seldom
>   used. 'm' type is special as it's four bytes only and first
>   byte represents a port number. So it's not fully up to the
>   definition of MIDI__MidiEvent.

Our URID mechanism is really a symbol mechanism that should have been
named as such...

> * It seems to be possible to send arrayed values with '['
>   ']', but I've never seen it used anywhere and can't figure
>   out how it's supposed to work. I guess it could be mapped
>   to a LV2_Atom_Vector, though.

A vector must contain all the same type, so this won't work.  You'd have
to use a tuple.

> osc.lv2 [2] is a working prototype of an extension
> implementing the mapping above, It's data only (aka URI
> definitions for object types and property keys) plus a
> utility header to help in easy forging.
> 
> An example of how I use this can be found in e.g. moony.lv2 [3].
> 
> Questions
> =========
> * Is the mapping that I've come up with sensible, stupid, ...?
> 
> * Anybody else interested in OSC <-> Atom mapping?
>   If so:
>   * Are the exotic types needed?
>   * Something else missing?

Cool.  Apologies for the super late reply, but OSC would be a nice thing
to have.  The mapping seems pretty reasonable to me, and the utilities
useful.

The main thing lacking on the code side of things from my perspective
seems to be an actual native/standard representation of OSC
bundles/messages?  It would be nice to take a buffer containing an OSC
message and simply call a utility function to write that in atom form to
a forge (or transmit / work with actual OSC between plugins and
whatnot).

Would you be interested in relicensing this under the LV2 license and
having an official extension based on it?

-- 
dr