Re: [LAU] Questions about LV2

On Wed, May 15, 2013 at 2:16 AM, Paul Davis <paul@email-addr-hiddenwrote:

>
>
>> 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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Wed May 15 20:15:03 2013