[LV2] Mapping of OSC to LV2 Atoms

[Hanspeter Portner]

On 19.10.2015 17:49, Spencer Jackson wrote:
> On Fri, Oct 16, 2015 at 10:03 PM, David Robillard <d at drobilla.net
> <mailto:d at drobilla.net>> wrote:
> 
> 
>     I assume by "key" you mean "type"...
> 
> Yes. Sorry.
>  
> 
>     Note that in OSC 1.1, "I" is impulse, i.e. a "bang" ala pd.  This is a
>     much more sensible and useful thing, I actually put a bang type in the
>     atom spec provisionally but it never made it because it seemed
>     superfluous and doesn't round-trip to Turtle particularly nicely.
> 
>     So - unsurprisingly, since this atom stuff is to some degree part of a
>     grandiose plan of mine to build a sort of LV2-based pd/Max/MSP - adding
>     an atom:Bang (or atom:Impulse?) seems fine to me :)
> 
> 
> I thought that was just a semantic change/clarification. I assumed
> infinitum was reference to the dirac delta function.
> 
> Regardless, I agree that atom:Impulse (or Bang) would be useful.
> 

atom:Impulse sounds more meaningful in my ears than atom:Bang.

I guess we have reached a 1-to-1 mapping then:

'i' -> LV2_Atom_Int
'f' -> LV2_Atom_Float
's' -> LV2_Atom_String
'b' -> LV2_Atom_Chunk
'h' -> LV2_Atom_Long
'd' -> LV2_Atom_Double
't' -> LV2_OSC_Timestamp                  NEW type
'T' -> LV2_Atom_Bool {.body = 1}
'F' -> LV2_Atom_Bool {.body = 0}
'N' -> LV2_Atom {.size = 0, .type = 0}
'I' -> LV2_Atom_Impulse                   NEW type
'S' -> LV2_Atom_URID
'c' -> LV2_OSC_Char                       NEW type
'm' -> LV2_Atom {.type = MIDI_MidiEvent}

LV2_Atom_Impulse||Bang would be added to the atom extension as it seems
to be useful enough on its own.

LV2_OSC_Timestamp would be added as a new atom type to the OSC extension
as its meaning is OSC-centric.

> On 15.10.2015 20:29, David Robillard wrote:
>> On Fri, 2015-06-19 at 22:33 +0200, Hanspeter Portner wrote:
>> Are you proposing general purpose unsigned integer Atom types:
> No.  Not until there's a really, really compelling reason this is
> absolutely required, because it's just more types for everyone to deal
> with.

What about LV2_OSC_Char, is this useful enough on its own to be put into
the atom extension, or should it be/remain OSC-centric?

I for sure have not missed an LV2_Atom_Char so far, so I'd be fine with
an LV2_OSC_Char.