[LV2] Mapping of OSC to LV2 Atoms

Spencer Jackson ssjackson71 at gmail.com
Fri Oct 16 09:41:47 PDT 2015

On Fri, Oct 16, 2015 at 9:38 AM, Hanspeter Portner <ventosus at airpost.net>

> Whether the OSC format string is needed or not depends on whether we can
> come up with a unique association for all OSC types (or any we want to
> support) with a corresponding LV2 type.
> For the basic types we could do without format string.
> 'i' -> LV2_Atom_Int
> 'f' -> LV2_Atom_Float
> 's' -> LV2_Atom_String
> 'b' -> LV2_Atom_Chunk
> For the extended types, we may or may not need a format string,
> depending on whether we get a special timestamp/unsigned type or not.
> 'h' -> LV2_Atom_Long
> 'd' -> LV2_Atom_Double
> 't' -> LV2_Atom_Long || LV2_Atom_uLong || LV2_OSC_Timestamp
> If 'h' and 't' both map to LV2_Atom_Long, we need the format string for
> bidirectional mapping.
> The booleans and MIDI we can map without format string.
> 'T' -> LV2_Atom_Bool {.body = 1}
> 'F' -> LV2_Atom_Bool {.body = 0}
> 'm' -> LV2_Atom {.type = MIDI__MidiEvent}
> 'N' and 'I' are not of great use, imho. Without format string we would
> have to give them individual types, too, like for the timestamp? We
> could also not implement them...
> 'N' -> LV2_Atom {.size = 0, .type = 0} || ???
> 'I' -> ???
> There are similar issues with 'c'har and 'S'ymbol, which may not be
> discriminatable from 'i' and 's', depending on what we map them to. We
> could also not implement them...
> 'c' -> LV2_Atom_Int || LV2_Atom_Char || ???
> 'S' -> LV2_Atom_String || LV2_Atom_URID
> I've never seen OSC types 'N', 'I', 'c', 'S' being used, we could just
> not implement them...
> So: If we want to get rid of the format string, we either have to add
> the missing unique Atom types or reduce the set of supported OSC types.
> I could well do with this reduced set of types: 'ifsbhdtTFm'.
> Which approach should we take, with or without format string?

Alright, I'm flip-flopping.
It does make sense to just map the data, rather than some attempt to make
special case osc-atom messages. That said, I figure sooner or later someone
will want "NIcS" so its better to take thought for them. 'S' seems to map
to URID. To me it makes sense to add an LV2_Atom_Char key. N and I would
make sense as new keys: LV2_OSC_Nil and LV2_OSC_Inf. These don't seem like
useful atom objects, so I'd leave them under the proposed OSC extension. I
believe this makes everything one to one.

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

More information about the Devel mailing list