4 Mar
2011
4 Mar
'11
3:24 p.m.
On 03/04/2011 01:53 PM, Stefano D'Angelo wrote:
Hence, in this case, I think we should exploit the
extensibility/decentralization of LV2: those who, like me, care about
"control rate" visualization hints may want to help on web UIs, for
example, the others might do the same with native GL.
The only thing that we all need to ensure is that things work well
together, whatever the host/plugin author choice is, also trying to
make the whole thing as painless as it can be for everybody.
Side note: this is yet another case where we could proceed to some
structured effort coordination at this point, but my feeling is that
this won't happen and the discussion will lead nowhere in the end.
There is one thing which stays on my mind.
I am familiar with developing JACK clients, not plugins. However, there has been
quite a few discussions in the past where JACK was advocated as a way to create
modules, DSP units dedicated to a specific task. In other terms: some kind of
plugins.
And what is absolutely nice about this is how it is non-intrusive. When working
on a JACK client, there are only audio input and output ports, a thin transport
layer, done. From these primitives, upon this bare but solid ground, a developer
creativity enjoys a lot of freedom.
However, there's been this critical and long-lasting session handling problem.
Fortunately, this problem doesn't occur for LADSPA and LV2 plugins, since saving
and restoring state is performed by the host.
But, with this UI/engine separation, whenever a developer comes out with an
innovative idea that he really likes, he's very likely to hit a wall because of
a specific LV2 technical constraint. And at the same time it takes an incredible
(if only possible) coordination effort to maintain LV2 to fulfill and
*anticipate* all needs.
But LV2 is extensible. So what I think is that in addition to the extensions
which imply UI/engine separation (and I understand that it's important in many
cases), there should be a DoWhatTheFuckYouWantInYourPlugin extension ;)
With such plugins, restoring/saving state would rely on passing a blob in
addition to restoring/saving the control ports values. There would be no such
thing as UI/engine separation. The plugin would be self contained. And hopefully
it would integrate nicely with other extensions such as midi.
I think that this extension, since it would only imply simple but powerful
primitives, would give a lot of freedom to developers who want that, and at the
same time be rather easy to maintain.
--
Olivier