Re: [LAU] Questions about LV2

On Wed, May 15, 2013 at 11:21 AM, David Robillard <d@email-addr-hidden> wrote:

> On Wed, 2013-05-15 at 10:27 -0700, J. Liles wrote:
> >
> > On Wed, May 15, 2013 at 2:16 AM, Paul Davis
> > <paul@email-addr-hidden> wrote:
> >
> > 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.
>
> *Forcing* IPC is stupid, as is not having the *possibility* of IPC.
>
> However this is not an OR, and would only be an issue for a crap design
> anyway. Conceptually, you use a protocol (i.e. POD "events" or
> "messages"), and leave the transport up to the host. Given
> multi-threading and RT this is pretty much how you have to do it anyway.
>
> If the host actually need IPC, then it can use it (e.g. a socket). If
> not, it can simply avoid all the complexity and overhead (e.g. memcpy,
> ringbuffer).
>
> There are many open questions about plugin APIs, but this is not one of
> them. The best solution is obvious, and doesn't require everyone to
> agree on IPC or not. Network protocol stacks have layers for a reason.
>
> Even if the transport was the same everywhere, making plugins
> specifically deal with all that would only result in a bunch of broken
> junk. (Ignoring a few rules), the plugin and UI don't have to worry
> about multi-threading, and talk to the world via synchronous POD. They
> aren't running in the same thread, of course, but that's the host's
> problem. Plugins should have *one* communication mechanism, and in LV2
> that mechanism is ports. Whether an event came directly from another
> plugin's output, or was delivered by carrier pigeon from the GUI running
> on a steam powered control panel in the desert is none of the plugin's
> concern.
>
> -dr
>
>
You've seen the consequences of these design decisions in Rui's response.
As extensible and awesome as your design may be on paper, the end result is
that users get overly fancy, in consistent (and probably slow) GUIs that
fiddle with parameters through hidden channels and have poor accessibility.
I think that is a real problem.

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Thu May 16 00:15:02 2013