[LV2] friendly reminder 2017 -- was: Qt5 plugin UIs and libsuil
stefan at space.twc.de
Tue Mar 14 04:08:22 PDT 2017
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.
> > > Clearly it was a mistake to not bake this in from day one,
> > > preventing
> > > all the horrific nonsense like external-ui that burdens both plugin
> > > and
> > > host authors with this crap, but oh well. Live and learn :)
> > I'm tempted to state the opposite. Allowing separation is a geeky
> > pipedream without any real world impact.
> Yeah, because "here's a pointer to your plugin instance, do whatever!"
> worked out *so* well for VST :P In any case, separation is only
> getting more relevant, IMO, but I don't see how that's the "opposite"
> position at all.
> (Separation is really just a side-effect of having a plugin control API
> that actually makes sense)
> The mistake is having this be something that pollutes the UI API and
> thus burdens both plugin and host authors at the same time, when the
> general problem ("I have a widget of some type and maybe this is not
> embeddable in the host and an out-of-process solution is necessary")
> is, well... general.
> There are pros and cons to separation, but that aside, external-ui is
> just a complete shit way to go about it.
Ok, I think I'll try to implement the out-of-process UI stuff. Not sure how
much spare time I can find for that, so I can't make any promises right now.
In any case, speaking of pointers to plugin instances, many plugins use the
instance access feature, so these will not work with out-of-process UIs.
So if they use a statically linked toolkit (like Robin says they should),
everything will be fine, but for instance
use Qt5 and instance access. So for these suil needs to load Qt5 into the host
process. We'll probably not able to really guarantee that everything works
flawless, but it probably makes sense to proceed to integrate the Qt5 patches
into suil properly.
Same is true for plugins that combine Gtk and instance access (lots of plugins
do that); suil probably needs to continue to support using Gtk within the host
process in this case.
The only other strategy I see to deal with instance access would be to put the
plugin's DSP and UI code into a seperate process. In this case we can guarantee
that everything works well, but at the cost of reduced efficiency.
Stefan Westerfeld, http://space.twc.de/~stefan
More information about the Devel