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

David Robillard d at drobilla.net
Sun Jan 5 08:33:12 PST 2014

On Sat, 2014-01-04 at 21:43 +0100, Kaspar Emanuel wrote:
> > My opinion of the external UI extension is that it is a crap solution,
> > because plugin UIs themselves shouldn't be implementing all that
> > external communication mechanism.
> In my case, my planned plugin (a re-write of SooperLooper) is likely a
> bit too complex to make sense as a plugin for some people. For some it
> will make more sense as a stand-alone jack client (as SL has been)
> that can change it's output and input ports and possibly host plugins
> itself.  So my plan is to release both LV2 and standalone and I am
> currently focusing on the stand-alone part.

Note the communication I am talking about here is just the UI stuff
(needed if the UI is actually a separate process), which is different
from talking to the plugin instance which works the same way regardless
of what UI extension you use.

> I could likely use LV2 communication even as a stand-alone client but
> I have put off doing anything related to LV2 for the time being
> because I find I keep reading through the docs and not getting it and
> asking people for help and still not getting it. I will take another
> swing at it but when it stops being fun the whole project loses it's
> point.
> I have settled on using Google Protobuf [1] to define the variables
> and generate communication code for me, at least for the standalone
> part. Its a lot more fun to write code like:
>      msg = MyMessage()
>      msg.foo = 1
>      send(msg.SerializeToString())
> than to deal with all the Forges, Frames and Atoms from LV2. I guess I
> am wishing for some higher level API to the Atom communication that
> will abstract some of the complexity away from me. Maybe a similar
> approach to Protobuf could be taken? My .proto file (used to define
> the variable I want to share) actually looks very similar to my .ttl
> files but with less details.
> [1]https://developers.google.com/protocol-buffers/docs/overview

Well, the point of the forge is that you are always concatenating, and
it works in realtime.  Thus, you can make messages in run() and send
them to your UI.  I tried to make it as easy to use as possible given
that requirement, and was personally quite happy with it, but apparently
failed because everybody finds it confusing anyway :(

I don't think it would be possible to make an API quite like that which
meets our requirements, particularly in C, though I'm all ears for
suggestions on how to make a better forge API.  The main restriction is
that we can't use dynamic allocation, period.

That said, is (essentially)


really that much more confusing than the above?

Maybe it would be slightly clearer with "start" in there for the
functions that just start a new object, like


but I was taking advantage of "forge" also being a verb to keep things
terse since the names are a bit long.

> > A correct solution would have plugin UIs define their widgets normally,
> > e.g. expose a Gtk2UI, then have a SINGLE separate facility, like a
> > library, do the wrapping business.  Then, it is embeddable if possible,
> > but usable regardless.
> I have begun writing my UI in PyQT4 in python and couldn't figure out
> yet if and how I could expose the Qt4 widget in a way so I could have
> an internal QtUI.

Well, using non-C languages like Python adds some difficulty since you
need to expose a C API.  Is it possible to get a pointer to your widget?
You need to expose your QWidget* with type


It is possible to make this easy from Python or similar languages with a
little skeleton code, but I don't know if anybody has done that work

> > I do not recommend implementing external UIs.  To my knowledge there is
> > no good reason to do so.  If you must, I highly recommend also exposing
> > your widget, in which case it will work fine in Jalv, among others.
> I will take another swing at understanding Atom communication and
> building an internal UI at some point. Worst case I offer an external
> UI but also will keep my definitions of float control ports (something
> in LV2 that I understand, hooray!) that will autogenerate an internal
> UI. It will be a tad ugly but could also be used a text-only or as an
> automation interface.

If you already have protocol buffer code, assuming your messages aren't
too massive, you can always just send string atoms around.

Hosts wouldn't know how to make sense of them, but it will work between
your UI and plugin at least.  Ultimately at some point in the future I
think hosts should be controlling things via standardized control
messages (so they can provide automation and generic UIs and whatnot)
which is what it sounds like your plugin needs (lots of dynamic
controls), but we are not quite there yet.


More information about the Devel mailing list