[LAD] [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Fri, 2011-01-14 at 23:05 +0100, fons at kokkinizita.net wrote:
> On Fri, Jan 14, 2011 at 11:29:06AM +0100, Tom Szilagyi wrote:
> 
> > On 14 January 2011 09:44, Philipp Überbacher <hollunder at lavabit.com> wrote:
> > >
> > > Is it really ardour-specific? Would be a pity.
> > > I'm aware that there's a lack of hosts, but if it's already so bad
> > > that a plugin is only supported in a single host, well, good night LV2.
> > 
> > IR is not really Ardour specific. Its just that 1) it relies on two
> > basic LV2 extensions (listed on its homepage), one for the GTK UI and
> > the other for a close in-process coupling between the UI and the
> > plugin via shared memory. 2) I personally don't have any interest in
> > using other hosts. But if an LV2 host provides the required
> > extensions, the plugin should work fine.
> 
> Given how easy it is to embded a window from app B into one of app A
> I wonder why LV2 (or any plugin standard) would bother with GUI-toolkit
> specific extensions at all.

It doesn't really, except where "extension" means a trivial thing that
literally just defines a URI for a particular toolkit.

> I just did a simple test:
> 
> * added a few lines (< 10) of code to jaaa,
> * started Ardour and opened its 'Locations' window,
> * and had jaaa running within it in seconds.
> 
> And that's wihout any cooperation from Ardour. A plugin could use
> whatever X11 toolkit it likes and with minimal support from the host
> do the same. Apart from that it would need some cooperation to transfer
> data between the dsp code and the GUI, but this can be made almost 
> transparent to the host.

This is currently a possibility, but it throws away the ability to do
things possible when the toolkits do match (notably embedding the GUI in
another window, such as the presets/etc bar ardour adds to the top).  It
is also not portable (depends on X11), assumes the concept of "window"
always makes sense(*), and has other problems.

In other words, this is a perfectly valid _implementation_ choice, but a
very poor _interface_ to define for plugin UIs.  See my other recent
reply in this thread for details.

Peace,

-dr

(* Think text-based UIs, UIs that draw to an existing drawable such as
Cairo or GL, etc)