[LV2] Mapping of OSC to LV2 Atoms

[David Robillard]

On Mon, 2015-10-19 at 09:49 -0600, Spencer Jackson wrote:
> On Fri, Oct 16, 2015 at 10:03 PM, David Robillard <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.

Yes, I just mean thinking about it in this way makes it seem a lot more
sensible in the context of LV2.

I remember why I didn't end up doing this, though: general hesitance to
add new atom types.  An impulse could be an Object with type Impulse,
which avoids needing a new atom type.  The breakdown of adding an
atom:Impulse type is something like:

* Pro: Small, simple in binary/C

* Con: No corresponding XSD type or RDF mapping, serialization for state
and whatnot gets a little funny.  One of the nice things about the
current stuff (as described in the atom spec and implemented by sratom)
is that you get "non-weird" output for most things that doesn't require
any LV2-specific knowledge to make sense of.

* Con: No ability to associate any other information with an impulse.
Using an Object means we could add strength or whatever there, if
needed.  This does not apply to the OSC case, though.

* Con: It's kind of like bool, but not.

Concretely, the options are:

1) Just use an Object.  Requires no spec changes, and the binary
representation corresponds directly to the serialized one:

<> :myimpulse [ a atom:Impulse ] .

2) Define a literal type.  Terse, but loses the ability to associate
other properties with an Impulse and introduces a non-standard (i.e.
non-xsd) literal data type:

<> :myimpulse "1"^^atom:Impulse .

A new atom type (i.e. thing to go in the LV2_Atom.type field) could be
serialized either way, though only an Object would allow sticking other
properties on an Impulse, like

<> :myimpulse [ a atom:Impulse; foo:strength 9000 ] .

The extra information thing is probably over-thinking, and one could
certainly argue that an impulse by definition has no other information
associated with it, but that's my line of thinking, anyway.  That said,
if we add a new atom type we need to decide how to serialize it for all
the existing infrastructure for state and so-on to work.

-- 
dr