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

David Robillard d at drobilla.net
Mon Jan 6 08:01:49 PST 2014

On Sun, 2014-01-05 at 23:41 +0100, Kaspar Emanuel wrote:
> On 5 January 2014 17:33, David Robillard <d at drobilla.net> wrote:
> > 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 really see how this is considerably simpler, other than the fact
that you have a specific struct (SimpleMessage) for your fields so you
can do message.foo instead of get the "foo" property from message.

It would be possible to make a tool where one can write message
definitions in Turtle and compile them to a C header to achieve a
similar thing.  Interesting idea, though I'm not sure this would really
help much or see much use...

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

Objects have properties, with a key and a value.  msg.foo = 5, the
property "foo" has value 5.

>  Who's head?

It's forge_property_head because you're just putting the key, not the
entire property with value yet.  It should/could have perhaps been
called lv2_atom_forge_key.

>  Am I
> forging or is it a forge?

Yes? :P

>  Why do I need to frame the forge?

The frame (ala "stack frame") keeps track of containers so you can build
nested objects, like an object with a list property.  The forge needs to
update the size field of the containers, so it needs this information.

The what/why/how isn't really important for the user though, you just
need to make a frame and pass a pointer to it.

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

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.

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.

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

... for values of "some" approaching 1 ;)

Embedding generally works fine and most users and developers are happy
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.

Well, LV2 isn't based on protocol buffers, so short of tools that
generate all this, if you have everything defined in both, there's
inherently going to be some repetition.


More information about the Devel mailing list