On 03/04/2011 01:53 PM, Stefano D'Angelo wrote:
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
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.
Linux-audio-dev mailing list