On Fri, 2011-03-04 at 11:02 +0000, Pedro Alves wrote: > 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?
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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
