[LV2] friendly reminder 2017 -- was: Qt5 plugin UIs and libsuil
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>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel