[LAU] Questions about LV2

J. Liles malnourite at gmail.com
Wed May 15 17:27:13 UTC 2013


On Wed, May 15, 2013 at 2:16 AM, Paul Davis <paul at linuxaudiosystems.com>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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20130515/96f9fe97/attachment.html>


More information about the Linux-audio-user mailing list