<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 16, 2015 at 9:38 AM, Hanspeter Portner <span dir="ltr"><<a href="mailto:ventosus@airpost.net" target="_blank">ventosus@airpost.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
</span>Whether the OSC format string is needed or not depends on whether we can<br>
come up with a unique association for all OSC types (or any we want to<br>
support) with a corresponding LV2 type.<br>
<br>
For the basic types we could do without format string.<br>
'i' -> LV2_Atom_Int<br>
'f' -> LV2_Atom_Float<br>
's' -> LV2_Atom_String<br>
'b' -> LV2_Atom_Chunk<br>
<br>
For the extended types, we may or may not need a format string,<br>
depending on whether we get a special timestamp/unsigned type or not.<br>
'h' -> LV2_Atom_Long<br>
'd' -> LV2_Atom_Double<br>
't' -> LV2_Atom_Long || LV2_Atom_uLong || LV2_OSC_Timestamp<br>
<br>
If 'h' and 't' both map to LV2_Atom_Long, we need the format string for<br>
bidirectional mapping.<br>
<br>
The booleans and MIDI we can map without format string.<br>
<br>
'T' -> LV2_Atom_Bool {.body = 1}<br>
'F' -> LV2_Atom_Bool {.body = 0}<br>
'm' -> LV2_Atom {.type = MIDI__MidiEvent}<br>
<br>
'N' and 'I' are not of great use, imho. Without format string we would<br>
have to give them individual types, too, like for the timestamp? We<br>
could also not implement them...<br>
<br>
'N' -> LV2_Atom {.size = 0, .type = 0} || ???<br>
'I' -> ???<br>
<br>
There are similar issues with 'c'har and 'S'ymbol, which may not be<br>
discriminatable from 'i' and 's', depending on what we map them to. We<br>
could also not implement them...<br>
'c' -> LV2_Atom_Int || LV2_Atom_Char || ???<br>
'S' -> LV2_Atom_String || LV2_Atom_URID<br>
<br>
I've never seen OSC types 'N', 'I', 'c', 'S' being used, we could just<br>
not implement them...<br>
<br>
So: If we want to get rid of the format string, we either have to add<br>
the missing unique Atom types or reduce the set of supported OSC types.<br>
<br>
I could well do with this reduced set of types: 'ifsbhdtTFm'.<br>
<br>
Which approach should we take, with or without format string?</blockquote><div><br></div><div>Alright, I'm flip-flopping.<br>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.<br><br></div><div>_Spencer<br></div><div><br> <br></div></div></div></div>