[LV2] Mapping of OSC to LV2 Atoms

[Spencer Jackson]

On Jun 19, 2015 2:33 PM, "Hanspeter Portner" <ventosus at airpost.net> wrote:

> Hi
>
> So, I'm in need of an atomified representation of OSC [1] to route it:
> * from plugin to UI and back
> * from plugin to plugin
> * from plugin to host and back
>

Coincidentally I was thinking about an application on this just this
afternoon. Great that you've already gone this far with it.


> Potential Issues
> ================
>
> * 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  think it would be best to match the osc method of having no data (and no
atoms) for the T F I N types. It is not a lot of overhead to have a couple
extra atom headers but why add it when the original spec doesn't have it?
Any existing code made to handle OSC messages would need extra modification
to handle this difference.


>
> * 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.
>

Just FYI In my OSC2MIDI utility we just ignore that first bit of a m type.
Not sure if thats really the best but it was surely the simplest.


> * 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.
>



> Questions
> =========
> * Is the mapping that I've come up with sensible, stupid, ...?
>

Looks good to me.


>
> * Anybody else interested in OSC <-> Atom mapping?
>

I've been thinking about it. I'd like to use OSC for microtonal control of
synths. I'm curious if you have a plan for Chimera's note event message
structure. I didn't notice any mention on your site. I read your postfix
documentation. That is good, but it would be nice to come up with a default
that could at hopefully be semi-standard for some interoperability between
products.


>   If so:
>   * Are the exotic types needed?
>

I don't think I'll use the exotic types at all, but, as you said, its good
to include them for completeness.


>   * Something else missing?
>

not that I can think of right now.


Those are just my initial thoughts. As I get deeper into an actual
implementation I might have some other insights. Others hopefully can chime
in with some more experience.

_Spencer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20150622/f7b84cb1/attachment.htm>