[LV2] Some thoughts/RFCs on the host stack

[David Robillard]

On Mon, 2018-05-14 at 22:47 +0100, Harry van Haaren wrote:
> On Mon, May 14, 2018 at 8:22 PM, David Robillard <d at drobilla.net>
> 
> > Currently I'm working on serd1 (really, serd2) which unifies serd
> > and
> > sord, to be the one non-LV2-specific library things are based on. 
> > Concretely, the main thing I'm shooting towards here is collapsing
> > the
> > billion (well, 3 or 4) different node types there currently are:
> > 
> > SerdNode (purely syntactic string stuff)
> > SordNode (SerdNode plus some store specific stuff)
> > LilvNode (SordNode plus some numeric stuff and an API wrapper)
> 
> Less things to learn gets a +1 from me

To be fair, host authors don't really need to care about this directly
and just use the lilv API, and plugin authors don't really at all, but
the overall complexity of the stack is quite high and there's a ton of
conversion crap in lilv and friends that could just not exist.

> I'm starting (hah) to see the world in a very Atom-y way recently,
> more on that in a sec...

'snice, innit? :)  Part of why I'd really like to distill all this
stuff is to make it more evident to newcomers what the point of all
this is.

> If we can reduce concepts that implement LV2 to Atoms as the data-
> structures,
> with a few known URIs, I'd see value there.
> 
> Not to bring in too much non-LV2 stuff to this conversation...
> however I'm currently
> thinking that creating mappings from HW Controllers to hosts /
> plugins would benefit
> from some "known" Atom message (think MIDI but then flexible and
> awesome ;)

The "known URI" thing is a bit of a problem here.  Mapped URIs are
great, but requiring them absolutely everywhere is really problematic. 
If you wanted to make a MIDI-like standard, for example, requiring all
participants to have a shared dynamic URI mapping mechanism for even
basic things is a MASSIVELY onerous requirement.  It also really sucks
for language bindings.

The standard atom types need to get static type numbers.  I'm not sure
exactly how to do this without breaking things, but I think it can be
done (some kind of "minimum dynamic URID" extension)

> Perhaps we can get a dev-discussion at the LAC?

Good idea, I'd be super into an LV2 "workshop" or whatever at LAC
specifically themed how to move LV2 itself forward.

-- 
dr