[LAD] Portable user interfaces for LV2 plugins.

[David Robillard]

On Thu, 2011-03-03 at 19:50 -0800, Sean Bolton wrote:
> On Mar 3, 2011, at 4:15 PM, David Robillard wrote:
> 
> > On Fri, 2011-03-04 at 08:56 +1300, Jeff McClintock wrote:
> >>> From: Paul Davis <paul at linuxaudiosystems.com>
> >>> Subject: Re: [LAD] Portable user interfaces for LV2 plugins.
> >>
> >>> VST3 allows the GUI to run in a different process?
> >>
> >> " The design of VST 3 suggests a complete separation of processor  
> >> and edit
> >> controller by implementing two components. Splitting up an effect  
> >> into these
> >> two parts requires some extra efforts for an implementation of  
> >> course.
> >> But this separation enables the host to run each component in a  
> >> different
> >> context. It can even run them on different computers. Another  
> >> benefit is
> >> that parameter changes can be separated when it comes to  
> >> automation. While
> >> for processing these changes need to be transmitted in a sample  
> >> accurate
> >> way, the GUI part can be updated with a much lower frequency and  
> >> it can be
> >> shifted by the amount that results from any delay compensation or  
> >> other
> >> processing offset."
> >
> > I would just like to point out that many/most of the movers and  
> > shakers
> > in this community have been advocating (often with much opposition) a
> > full plugin/UI split for years. I guess now that the commercial guys
> > have finally gotten around to it the stupid arguments (e.g. that it's
> > not needed because VST or whatever doesn't have it) go away. Hooray.
> >
> > For the record: It's now official that the old VST way was garbage,  
> > and
> > a complete plugin <=> UI split is an obvious requirement, not
> > unrealistic idealism or a topic at all up for debate.
> 
> Hmm, if you want a "complete plugin <=> UI split", doesn't that mean
> something like the lv2_external_ui extension, which puts the UI in
> a separate process (perhaps even on a different computer), rather
> than the libsuil approach that could easily lump the host, numerous
> plugins, Qt, GTK+, and who knows what else (GL? SDL? segfaults?)
> all into one process? Or am I not understanding what you mean by
> "complete split"?

No, the issue is communication between UI and plugin.

Whether or not the UI runs in the same process as the "UI host" is a
different thing entirely.

(Also, note that Suil could do the separate UI process thing too. Suil
is not an "only in-process" library, it is a library to deliberately
abstract the entire question away. Right now it's all in-process because
embedding is awesome and there's no reason to do otherwise and lose it)

-dr