15 May
2013
15 May
'13
10:01 p.m.
On Wed, May 15, 2013 at 11:21 AM, David Robillard <d(a)drobilla.net> 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.
On Wed, May 15, 2013 at 2:16 AM, Paul Davis
<paul(a)linuxaudiosystems.com> 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
15 May
15 May
10:12 p.m.
New subject: Questions about LV2
Hello Jonathan!
Well it isn't that bad. I admit this hidden communication is slightly
awkward and I'd sometimes like it differently. but as was said, jalv supports
a few of those newer standard features, that get used. Although I must admit,
that I can start jalv, but not control it. :-)
Luckily there are other synths around too and there's much fun to be had
with those as well. :-)
Warm regards
Julien
----------------------------------------
http://juliencoder.de/nama/music.html
16 May
16 May
1:10 a.m.
New subject: Questions about LV2
On Wed, May 15, 2013 at 01:01:02PM -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.
Since everybody seems to air his/her opinions about this I'll add mine.
Considering that the DSP and GUI parts of a plugin could end up in different
places (on separate machines), considering that in that case the communication
will be asynchronous no matter how it is presented - whatever API is designed
to support it should make it clear that it *is* asynchronous even if it doesn't
have to be if the two parts happen to be in the same process. Which probably
means that it should be based on exchanging messages.
Next question is who should take care of transporting such messages, and
I'd say it should be the host if DSP and GUI are on the same, or the hosts
(plural) if they are not, using whatever mechanism they like. In both cases
the interfaces presented to the two plugin components should be the same.
Next question is if the host(s) should interpret such messages, and my answer
to that is a definite *no*. IMHO the DSP-GUI communication is private to the
plugin. If the plugin designer wants to expose some or all control ports for
automation, MIDI binding or OSC mapping, he/she should do that explicitly.
The mere existence of e.g. a slider on the GUI and a corresponding control
port on the DSP side should not enable the host to access the control port.
This of course assumes that all plugins provide their own GUI, and it will
never be the host's task to create a GUI for a plugin (unless maybe if the
plugin explicitly asks for this to happen, in which case it has to supply
the required information).
Related questions are if automation, MIDI binding and OSC mapping should
take place at the DSP side or the GUI side. MIDI binding makes most sense
at the GUI side - in most cases the user will want to map e.g. a slider to
some HW controller, and since only a linear range from 0 to 127 is available
it makes sense to include the position to value mapping of the slider in the
MIDI binding, and you can't expect 'sample accurate' control via MIDI anyway.
And if the DSP and GUI are on separate machines, the user and his MIDI HW are
probably near the one that does the GUI, while the DSP part could be in a
machine room on another floor. OSC mapping could make sense at the DSP side.
Automation is a dubious case. In systems such as Meyer Sound's D-Mitri, all
automation is done client side, i.e. by the CueStation software which in our
context corresponds to the GUI. Even in that case it could be 'sample accurate'
if desired, but I can't see any case where automation has to be sample accurate
- if it is used for anything else than replaying manual input it becomes some-
thing entirely different that proabably requires its own solution.
Probably heresy in some people's mind, but so be it.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)
1:39 a.m.
New subject: Questions about LV2
Hello Fons!
Maybe I'm missing something. But what is the point in having seperate GUIs
and DSP cores, if the plugin can so easily fully depend on the GUI? Thinking
back to the early days of LV2, wasn't it just part of the point to decouple
GUI from DSP, so that there could be other ways of controlling the plugin?
Allowing hosts to create GUIs.
I seem to remember, that there were problems with a few VST plugins causing
all sorts of problems, because they were useless or simply un-runnable without
their GUIs, but their GUIs wouldn't work in our environments.
I thought, that the intention was to create a very flexible plugin system,
that could be plugged in anywhere.
As I say,I may have missed the point. In any case, I'm no developer, so I
have no grounds for complaining. I can like it or lump it. That too is part of
the freedom. and yes I see, that you only voiced an opinion and not a
guideline or law. I'm tagging this on, because I feel, that these days I
sometimes let my frustration get away with myself, which is unfair to those,
who haven't caused it. And this state of affairs isn't caused by any software
at all. :-)
Warm regards
Julien
----------------------------------------
http://juliencoder.de/nama/music.html
4406
days inactive
4406
days old
linux-audio-user@lists.linuxaudio.org
3 comments
3 participants
participants (3)
-
Fons Adriaensen -
J. Liles -
Julien Claassen