Re: [LAU] Questions about LV2

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: David Robillard <d@...>
Cc: linux-audio-user <linux-audio-user@...>
Date: Wednesday, May 15, 2013 - 8:01 pm

--089e011847f69580ba04dcc735c0
Content-Type: text/plain; charset=UTF-8

On Wed, May 15, 2013 at 11:21 AM, David Robillard wrote:

> On Wed, 2013-05-15 at 10:27 -0700, J. Liles wrote:

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.

--089e011847f69580ba04dcc735c0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, May 15, 2013 at 11:21 AM, David Robillard <d@drobilla.net=

On Wed, 2013-05-15 at 10:2=
7 -0700, J. Liles wrote:
ms.com> wrote:
GUI is (a) stupidly expensive (b) stupidly

*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. =C2=A0Conceptually, you use a protocol (i.e. POD "events"=
or
"messages"), and leave the transport up to the host. =C2=A0Given<=
br>
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). =C2=A0If=

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. =C2=A0The best solution is obvious, and doesn't require everyone =
to
agree on IPC or not. =C2=A0Network 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. =C2=A0(Ignoring a few rules), the plugin and UI don't have to wor=
ry
about multi-threading, and talk to the world via synchronous POD. =C2=A0The=
y
aren't running in the same thread, of course, but that's the host&#=
39;s
problem. =C2=A0Plugins should have *one* communication mechanism, and in LV=
2
that mechanism is ports. =C2=A0Whether an event came directly from another<=
br>
plugin's output, or was delivered by carrier pigeon from the GUI runnin=
g
on a steam powered control panel in the desert is none of the plugin's<=
br>
concern.

-dr
You've seen the cons=
equences 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 o=
verly fancy, in consistent (and probably slow) GUIs that fiddle with parame=
ters through hidden channels and have poor accessibility. I think that is a=
real problem.

--089e011847f69580ba04dcc735c0--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
Re: [LAU] Questions about LV2, J. Liles, (Wed May 15, 8:01 pm)
Re: [LAU] Questions about LV2, Fons Adriaensen, (Wed May 15, 11:10 pm)
Re: [LAU] Questions about LV2, Julien Claassen, (Wed May 15, 11:39 pm)
Re: [LAU] Questions about LV2, Julien Claassen, (Wed May 15, 8:12 pm)