2011/3/4 Olivier Guilyardi <[email protected]>: > 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.
Actually control ports do not define the state alone, the state also includes plugin-specific data (the stuff the LV2_Handle thing should point to) - and that is generally a binary blob anyway (unless you do some other kind of storing/restoring, like with key/value pairs, etc.). > 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. Why do you hate yourself so much? /me buys popcorn and waits for Dave to bash you hard. :-) _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
