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

[Stefan Riha]

On Fri, Apr 7, 2017 at 4:09 PM, Hanspeter Portner <
dev at open-music-kontrollers.ch> wrote:

> 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 had no clue, thanks for clarifying!


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

Indeed, I read about that, they added it recently to the library I use.
I'll try that.


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


Yes, that was the idea! Thanks for the link.


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

Browser incompatibilities of course defeat the purpose of having a web gui,
I can see that. Ok I'll keep GL in mind.





> _______________________________________________
> Devel mailing list
> Devel at lists.lv2plug.in
> http://lists.lv2plug.in/listinfo.cgi/devel-lv2plug.in
>


Thanks a lot for your help!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lv2plug.in/pipermail/devel-lv2plug.in/attachments/20170407/cda88259/attachment-0001.htm>