On Wed, May 15, 2013 at 11:21 AM, David Robillard <d@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
> forcing IPC on the GUI is (a) stupidly expensive (b) stupidly*Forcing* IPC is stupid, as is not having the *possibility* of IPC.
> 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.
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@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
