3 Mar
2011
3 Mar
'11
8:56 p.m.
From: Paul Davis <paul(a)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."
The host needs
to see every parameter tweak. It needs to be between the
GUI
and the DSP to arbitrate clashes between
conflicting control surfaces.
It's
the only way to do automation and state recall
right.
well, almost. as i mentioned, AU doesn't really route parameter
changes via the host, it just makes sure that the host can find out
about them. the nicest part of the AU system is the highly
configurable listener system, which can be used to set up things like
"i need to hear about parameter changes but i don't want to be told
more than once every 100msec" and more. It's pretty cool. 
4 Mar
4 Mar
1:17 a.m.
New subject: Portable user interfaces for LV2 plugins.
On Fri, 2011-03-04 at 08:56 +1300, Jeff McClintock wrote:
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.
It's not always us playing catch-up :)
-dr
From: Paul
Davis <paul(a)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." 
4:50 a.m.
New subject: Portable user interfaces for LV2 plugins.
On Mar 3, 2011, at 4:15 PM, David Robillard wrote:
On Fri, 2011-03-04 at 08:56 +1300, Jeff McClintock
wrote:
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"?
-Sean
From:
Paul Davis <paul(a)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."
5:42 a.m.
New subject: Portable user interfaces for LV2 plugins.
On Thu, 2011-03-03 at 19:50 -0800, Sean Bolton wrote:
On Mar 3, 2011, at 4:15 PM, David Robillard wrote:
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
On Fri, 2011-03-04 at 08:56 +1300, Jeff
McClintock wrote:
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"? From:
Paul Davis <paul(a)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." 
12:02 p.m.
New subject: Portable user interfaces for LV2 plugins.
On Friday 04 March 2011 04:40:06, David Robillard wrote:
Right now it's all in-process because embedding is
awesome and
there's no reason to do otherwise and lose it)
Hmm? How isn't embedding orthogonal to separate-process?
What is it you lose again?
--
Pedro Alves
12:32 p.m.
New subject: Portable user interfaces for LV2 plugins.
On Fri, Mar 4, 2011 at 6:02 AM, Pedro Alves <alves.ped(a)gmail.com> wrote:
On Friday 04 March 2011 04:40:06, David Robillard
wrote:
if the GUI is in another process, its really absurdly hard for the
host to add its own controls to the window. not impossible, but a
level of hard that doesn't actually buy the user (or developer)
anything. this means that the kinds of generic "every plugin" controls
like "bypass" or "preset" that ardour adds to LADSPA and AU windows
would vanish. not a huge cost, but a real one.
Right now it's all in-process because
embedding is awesome and
there's no reason to do otherwise and lose it)
Hmm? How isn't embedding orthogonal to separate-process?
What is it you lose again?
--
Pedro Alves
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
12:48 p.m.
New subject: Portable user interfaces for LV2 plugins.
2011/3/4 Paul Davis <paul(a)linuxaudiosystems.com>om>:
On Fri, Mar 4, 2011 at 6:02 AM, Pedro Alves
<alves.ped(a)gmail.com> wrote:
Total newbie for "advanced UI" topics here.
Can't you put those controls outside of the embedded UI window that's
running into another process? Or maybe this is not the issue?
On Friday 04 March 2011 04:40:06, David Robillard
wrote:
if the GUI is in another process, its really absurdly hard for the
host to add its own controls to the window. not impossible, but a
level of hard that doesn't actually buy the user (or developer)
anything. this means that the kinds of generic "every plugin" controls
like "bypass" or "preset" that ardour adds to LADSPA and AU windows
would vanish. not a huge cost, but a real one. Right now it's all in-process because
embedding is awesome and
there's no reason to do otherwise and lose it)
Hmm? How isn't embedding orthogonal to separate-process?
What is it you lose again?
8:13 p.m.
New subject: Portable user interfaces for LV2 plugins.
On Fri, 2011-03-04 at 11:02 +0000, Pedro Alves wrote:
On Friday 04 March 2011 04:40:06, David Robillard
wrote:
If we are going to confuse the discussion by talking about external
plugin UI processes as well, then there are /three/ processes involved:
1) The plugin host, e.g. audio engine.
2) The UI host, e.g. graphical host UI program
3) The plugin UI process
Accordingly, there are two 'process splits' involved. The 1..2 split is
necessary. The 2..3 split needs to die, at least as far as UI authors
explicitly implementing this. The "external UI" extension is a kludge
and an error, and a slew of both immediate and long-term problems.
Making it go away needs to happen ASAP. Those things are, in theory,
orthogonal, yes. They aren't in practise because this extension's API is
broken. That's basically the problem.
The current strategy is to abstract all this away from hosts entirely in
host libraries (such as SLV2), since clearly the entire community can
not move forward on this issue when the compatibility problems cut all
the way from plugin UI to host implementations. With the appropriate
abstraction in place, things can move forward gracefully.
As for the implementation details of embedding, assuming you can embed
toolkit X in toolkit Y (which is true of all toolkits for which LV2
plugin UIs currently exist), then using a separate process is simply
bloat. I don't think that is particularly relevant or interesting
though, both Qt and Gtk provide embedding APIs, how they work is a
magical mystery, who cares. The problem is that these issues are
affecting the API which plugin UI authors use to implement their UIs,
and that is a big problem.
-dr
Right now it's all in-process because
embedding is awesome and
there's no reason to do otherwise and lose it)
Hmm? How isn't embedding orthogonal to separate-process?
What is it you lose again?
5073
days inactive
5074
days old
linux-audio-dev@lists.linuxaudio.org
7 comments
6 participants
participants (6)
-
David Robillard -
Jeff McClintock -
Paul Davis -
Pedro Alves -
Sean Bolton -
Stefano D'Angelo