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

Kaspar Emanuel kaspar.emanuel at gmail.com
Sun Jan 5 14:41:27 PST 2014


On 5 January 2014 17:33, David Robillard <d at drobilla.net> wrote:
> 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.

Oh yeah for sure, wholly different process. My hope is that the
back-end can run headless on some embedded system if need be. But I
don't quite follow, you do mean the communication between UI and
back-end (DSP) right?

> 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 :(

More of an aside: I am using Protobuf in realtime code at the moment
using nanopb[1] which avoids all memory allocation. So my Python GUI
is able to communicate with the real-time part of my DSP directly
using a UNIX socket (unless someone tells me this is a bad idea).

[1]: http://koti.kapsi.fi/jpa/nanopb/

>
> 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)
>
> forge_object();
> forge_property_head(foo);
> forge_int(1);
>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

>lv2_atom_forge_start_object();
>lv2_atom_forge_start_property(foo);
>lv2_atom_forge_int(1);
>
>but I was taking advantage of "forge" also being a verb to keep things
>terse since the names are a bit long.

I think if I spend a bit more time on Atom communication I will
understand and use it. Your examples look simple enough. I still think
that the existing API could be wrapped in something a bit more user
friendly. Part of the problem seems to be that I don't really
understand the vocabulary used. Who's property? Who's head? Am I
forging or is it a forge? Why do I need to frame the forge? I guess I
wish I didn't have to try and learn these concepts and jargon as I
just want to send a damn message and I have already described in
detail what the data looks like (in the ttl). I will get there
eventually I am sure...

>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

>http://lv2plug.in/ns/extensions/ui#Qt4UI

>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
>already.

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).

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

That seems like it would be a nice way of doing it for the time being.
I could still leave the float ports which will work nicely for
automation or a text interface. What annoys me really is that I have
redundant information in my ttl files and my proto files which I have
to duplicate. I have started to use the extra info in the ttl files
(like the max and min of a given port) to generate parts of my
standalone jack-client GUI at least.



More information about the Devel mailing list