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

Kaspar Emanuel kaspar.emanuel at gmail.com
Mon Jan 6 09:26:18 PST 2014

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.

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

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

> 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?

> > I will investigating this. But I am a bit concerned that it might be a
> > wasted effort since some plugin host authors don't seem to happy with
> > the current approach of embedding widgets (though I have yet to see
> > any problems with it).
> ... for values of "some" approaching 1 ;)
> Embedding generally works fine and most users and developers are happy
> with it.

Well rncbc and falkTX seem to both be expressing some concerns so
that's two popular hosts? Aside from that most hosts support the
external-ui extension. I can't say I understand the issues with
embedding widgets at all but there is definitely some resistance to it
so I am concerned about long-term support for it, especially if I am
using a "heavy" toolkit that a given host might not want to

P.S. Is it me or is http://lv2plug.in/ really slow lately?

More information about the Devel mailing list