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

[Hanspeter Portner]

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:

https://github.com/moddevices/modgui-embed

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