On Wed, May 15, 2013 at 2:16 AM, Paul Davis <paul@xxxxxxxxxxxxxxxxxxxxx> wrote:
Without completely removing this mechanism and forcing custom plugin GUIs to run in a separate process (and therefore use a formally defined interface to the DSP component) LV2 will always be inadequate for your purposes.
forcing IPC on the GUI is (a) stupidly expensive (b) stupidly complex (c) limits host options.
Regarding (A), expensive in terms of what? Pulling the libs for a giant GUI toolkit into my host process is expensive. Expensive in terms of communication? No. A few knobs and sliders and even a scope or eq graph are not going to present any bandwidth problems even on modest hardware. And how many plugin GUIs are you going to have open simultaneously anyway?
Regarding (B), I would say it's smartly complex. Avoiding *necessary* complexity for short term gains is stupid. It doesn't *have* to be complex, either for the host or the plugin, as the plugin author is free to provide shitty hints, and the host is free to provide a shitty GUI. But what this complexity buys is robustness, stability, and guarantee that the host can see all communication with the GUI.
Regarding (C), I believe it expands host options. With better hints and a complete view of plugin capabilities, the host can generate a more usable interface than the plugin author is ever likely to, and the host can do this for *all* plugins. If it's things like embedded windows that you desire, don't forget that XEMBED still works across process boundaries.
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
