<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, May 14, 2018 at 8:22 PM, David Robillard <span dir="ltr"><<a href="mailto:d@drobilla.net" target="_blank">d@drobilla.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I've been finding some time to put into my long-enqueued project of<br>
cleaning up the LV2 host stack (probably towards putting everything<br>
into a single distribution to be more palatable to people who don't<br>
just rely on package managers, and generally being a lot simpler). <br>
Since the host mess has become a topic of conversation lately, here's a<br>
related brain dump / progress report:<br>
<br>
Currently I'm working on serd1 (really, serd2) which unifies serd and<br>
sord, to be the one non-LV2-specific library things are based on. <br>
Concretely, the main thing I'm shooting towards here is collapsing the<br>
billion (well, 3 or 4) different node types there currently are:<br>
<br>
SerdNode (purely syntactic string stuff)<br>
SordNode (SerdNode plus some store specific stuff)<br>
LilvNode (SordNode plus some numeric stuff and an API wrapper)<br></blockquote><div><br></div><div>Less things to learn gets a +1 from me<br></div><div>  <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The idea is to merge these all into one, and expose SerdNode directly<br>
in the Lilv API, so there's just one type of data node everywhere. <br>
This will greatly simplify a lot of things, but leads me to what I'm<br>
currently wondering: we also have these atom things.<br>
<br>
I think one of the good things about LV2, static data and not needing<br>
to run code to just discover plugins, is also a big weakness, because<br>
we have to make hard decisions about what's static and what's dynamic,<br>
and these worlds are quite different.  Certain dynamic functionality<br>
(say, dynamic channel configuration) is still missing because of this. <br>
Things would be nicer if dealing with the static data (via lilv) and<br>
interacting with the plugin (via atoms) were as similar and compatible<br>
as possible.  In an ideal world, nearly indistinguishable.<br>
<br>
... and there's the tie-in.  Currently my SerdNode is:<br>
<br>
struct SerdNode {<br>
        size_t        n_bytes;<br>
        SerdNodeFlags flags;<br>
        SerdType      type;<br>
        // data immediately follows here<br>
};<br>
<br>
Look familiar?  The flags are an optimization which can be dispensed<br>
with without too much trouble, leaving:<br>
<br>
struct SerdNode {<br>
        size_t   n_bytes;<br>
        SerdType type;<br>
        // data immediately follows here<br>
};<br>
<br>
Toss the ability to deal with very large (gigabyte scale) individual<br>
values (which is... maybe fine?) and we're left with:<br>
<br>
struct SerdNode {<br>
        uint32_t n_bytes;<br>
        SerdType type;<br>
        // data immediately follows here<br>
};<br>
<br>
Which just so happens to be binary compatible with LV2_Atom.<br></blockquote><div><br></div><div>I'm starting (hah) to see the world in a very Atom-y way recently, more on that in a sec...<br></div><div><br></div><div>  <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So I'm wondering if this is worth pursuing.  To make this work, we<br>
would have to deal with the dynamic atom type problem (previously<br>
mentioned here, and would make a bunch of other things much simpler on<br>
its own), carving out some space for static type IDs.<br>
<br>
Then, lilv could talk in a unified way about/with static data and live<br>
plugins. Conceptually this is quite nice, but I haven't thought much<br>
about what this concretely brings.<br>
<br>
Being able to ask, via lilv, if a plugin supports a particular message<br>
(say, OSC), and have this transparently use the static data or talk to<br>
an instance if it depends on configuration?  Doing the same for channel<br>
configuration?  Loading messages from disk (plugin data, saved state,<br>
host specific stuff, etc), and passing them directly to a running<br>
plugin instance?<br>
<br>
In terms of clarity, I think it would help a lot of LV2 had a simple<br>
data model (basically the atom one, a relatively simple set of strings<br>
and numbers and stuff), and 100% of host and plugin communication used<br>
it.  Host authors wouldn't really need to care (much) that there's this<br>
static RDF data, and also a plugin to talk to, because it all speaks<br>
the same language and lilv hides any gory details in most places.  Kids<br>
these days like JSON, right?  It's not far off, just a lot more<br>
meaningful :)<br>
<br>
It would be quite nice if, say, a { 4, LV2_INT, 12345 } struct could<br>
represent the int 12345 absolutely everywhere in the LV2 ecosystem. <br>
<br>
... so, that's that thought.  Sorry for the wall of text, I can't<br>
really distill this into something more concrete, I'm just trying to<br>
find the common core of nicety here and strip away as much other crap<br>
as possible with the benefit of hindsight (the LADSPA-plus-a-thing-or-<br>
two days are long ago, now).  Thoughts of whatever variety welcome.<br></blockquote><div><br></div><div>In general I'm nodding my head at the above. Atoms (or some basic "nugget" of<br></div><div>data to communicate between things) make a lot of sense.<br><br></div><div>If we can reduce concepts that implement LV2 to Atoms as the data-structures,<br></div><div>with a few known URIs, I'd see value there.<br><br></div><div>Not to bring in too much non-LV2 stuff to this conversation... however I'm currently<br>thinking that creating mappings from HW Controllers to hosts / plugins would benefit<br></div><div>from some "known" Atom message (think MIDI but then flexible and awesome ;)<br><br></div><div>Perhaps we can get a dev-discussion at the LAC?<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<br>
<span class="HOEnZb"><font color="#888888"><br>
-- <br>
dr<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">Regards, and hopefully see ye'all soon in Berlin :) -Harry<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><br><a href="http://www.openavproductions.com" target="_blank">http://www.openavproductions.com</a></div>
</div></div>