[LV2] friendly reminder 2017 -- was: Qt5 plugin UIs and libsuil

Hanspeter Portner dev at open-music-kontrollers.ch
Thu Apr 6 23:09:01 PDT 2017

On 07.04.2017 06:38, Stefan Riha wrote:
> Hi, trying to bottom-post:
> On Tue, Mar 14, 2017 at 10:08 PM, Stefan Westerfeld <stefan at space.twc.de
> <mailto:stefan at space.twc.de>> wrote:
>        Hi!
>     On Fri, Mar 10, 2017 at 07:19:24PM +0100, David Robillard wrote:
>     > On Wed, 2017-03-08 at 20:23 +0100, Robin Gareus wrote:
>     > > On 03/08/2017 08:04 PM, David Robillard wrote:
>     > > I'd love to see an efficient IPC mechanism that works x-platform on
>     > > all
>     > > the platforms that LV2 works on.
>     >
>     > Nobody ever got fired for using TCP sockets.
>     Yes, right. One could use a pipe() if the platform supports that and
>     fall
>     back to identical-API sockets.
>     >
>     > "Efficient", well, yeah.  No.  This is a fallback (or single-plugin
>     > host) mechanism, not something ideal.  That said, it can easily be good
>     > enough.  Hell, people do this for actual plugins and kinda sorta get
>     > away with it, most UIs are waaaaaaaaaaaaayyyyyyyy less demanding.
>     We don't need hard-RT for UI anyway, so this should be fine.
> I'm a programming beginner and also interested in learning about TCP. 
> I thought it's too slow/expensive for audio. But maybe it's nice for
> testing plugins, e.g. if a host doesn't provide a generic gui, or if the
> "generic logic" produces cumbersome results. Since it was brought up in
> this thread, I was wondering if anybody could outline in more detail how
> to do this properly?

The conversation is about using some IPC mechanisms (pipe/TCP) for
communication from host to plugin UIs running in a separate process
space. It would be the hosts job to do that for you. The plugin author
wouldn't need to implement that.

> I should say that I understand about 20% of what is being discussed
> here, so I appreciate references to tutorials or introductions
> (particularly using networking protocols).
> I tried to get something working with as little effort as possible,
> probably very naively: 
> At UI instantiation I launch a TCP listener in a new thread (A) that
> listens on an OS-assigned port. When the connection is established, the
> stream is split into a "receiver" and a "sender". The "receiver", which
> in my case receives from a Web browser, is blocking, and so must be put
> into another thread (B), along with the LV2 write_function and the
> controller. The port_event() function is connected to the "sender" with
> a so-called "channel". Side note: A "channel" is a Rust thing that
> provides asynchronous communication between threads, surely there is
> something equivalent in C, but I don't know how to call it.

Surely there is a non-blocking version of the receiver? You'd put that
into an ui:idleInterface which will be called continuously with a fixed
update rate by the host.

> So in other words, there are two new threads for a single plugin
> instance, which is probably very bad. True?
> Is a better way to do it, to let the ui be a client only, and connect to
> a standalone server? That wouldn't reduce the overall load, but the
> server could live on a different CPU core or even CPU?

Well, I don't know what you actually try to solve here... Do you want to
run your UI in the browser? Then you may be interested in this:


> When I brought up websockets in a previous thread (almost a year ago)
> Hanspeter pointed me to his Moony plugin. However, I could not find
> stuff related to websockets, tcp or the like.

It must still be there in the git logs somewhere. I've migrated the UI
to a GL implementation since, as I don't want to deal with browser
incompatibilities, an UI in the browser gives a bad user experience and
the ui:showInterface is not (reliably) implemented across LV2 hosts.

Implementing your UI in GL and drawing it to the platform's native
surface will give you the least pain, IMHO.

More information about the Devel mailing list