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

Stefan Riha hoitaus at gmail.com
Thu Apr 6 21:38:29 PDT 2017

Hi, trying to bottom-post:

On Tue, Mar 14, 2017 at 10:08 PM, Stefan Westerfeld <stefan at space.twc.de>

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

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.

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?

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.

Thanks, Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20170407/07f2ac1a/attachment.htm>

More information about the Devel mailing list