[LV2] [PATCH 5/5] add external UI as valid UI

[David Robillard]

On Mon, 2014-01-06 at 18:26 +0100, Kaspar Emanuel wrote:
> Thanks for the response and explanation David. It will use this email
> as a reference when I get back implementing atom comms.
> 
> On 6 January 2014 17:01, David Robillard <d at drobilla.net> wrote:
> > You have already described in detail what the data looks like in ttl?
> > Where/why?  Most atoms users haven't done this since you don't need to.
> 
> Well, you are probably right, it was more for the float ports when I
> did the ttl description. But even so it would be nice to describe the
> atom (especially patch) data in ttl and then just have to do a couple
> of function calls in C to get the data across.

Ah, I see.  Yeah, control ranges and stuff will be duplicated if you
have control ports and also events.  That's not going to be a fun
transition if we ever manage to move everything to event-based control.

> When I look at eg04-sample for instance the calls in sampler_ui.c look
> OK (could still be simpler I think -- given that the communication
> mechanism is pretty much set in stone at that point) but when I glance
> over at the definition of write_set_file in uris.h I want to take
> cover and hide (though less so with the explanations from your last
> email).

I guess the body of this function would have verbose comments describing
everything like "append the key of the eg:sample property".  I didn't
think this much excruciating detail was necessary given the message is
shown in Turtle above.

Such a paragraph doesn't seem all that much more informative than the
function call, to me, but I also wrote it...

lv2_atom_forge_key(forge, uris->patch_property)

is about as clear as it gets.  property_head was a bad name, and the
context honestly just exists to fill 4 bytes and isn't really used by
anything at this point.  Perhaps another improvement would be returning
the frame, for code something like:

	LV2_Atom_Forge_Frame msg = lv2_atom_forge_object(
		forge, 1, uris->patch_Set);

	lv2_atom_forge_key(forge, uris->patch_property);
	lv2_atom_forge_urid(forge, uris->eg_sample);

	lv2_atom_forge_key(forge, uris->patch_value);
	lv2_atom_forge_path(forge, filename, filename_len);

	lv2_atom_forge_pop(forge, &msg);

	return set;

This is about as clear as I think it gets; suggestions for further
improvement welcome.

> As far as I understand you are basically writing RDF during the
> write_set_file call. Couldn't this be done as ttl?

It's written in ttl (and can be converted to/from that) for human
friendliness, but actually using a string serialisation for RT control
would be ridiculously bloated and slow.  The main point of atoms is they
are a compact native binary representation of data, which can also
happen to be serialized to Turtle.

It's extremely powerful and elegant in many ways, but clearly the
usability of the surrounding utilities currently needs work.

> > If you think a protocol-buffer like tool to compile this to C struct
> > definitions would be useful, I think it's a cool idea, though I'm not
> > sure how it could do sequences and lists... I suppose it would have to
> > be restricted to fixed lengths and use arrays.
> 
> I will think the idea over once I am actually able to use Atom comms
> for my purposes and try and  see if it still holds water.
> 
> For nanopb, you define maximums in your .proto or .options file.
> Regular protobuf uses dynamic allocation. How is the varying length
> actually dealt with for atom sequences? I guess it's the buffer size
> you set for your forge?

You can just keep appending stuff until you run out of space.  The
protocol buffer special language/precompile thing is nice in some ways,
but is also quite limiting in other ways.  With the atom stuff you can
write whatever properties you like, you don't need rigid message
definitions set in stone beforehand.

> I can't say I understand the issues with
> embedding widgets at all

Neither do I... which is precisely why they (allegedly) still exist.

I spent my holiday emptying out my bug tracker.  As far as I know, suil
works perfectly in all cases.  I can't fix what I don't know about.

> I am concerned about long-term support for it

This is a non-issue.  Embedding works based on having a pointer to a
widget.  (Nearly) all UIs have a "widget" of some variety.  It's not a
one or the other thing: external vs embedded is something you can - and
should - build *on top of* that.

-- 
dr