Re: [LAD] [ANN] IR: LV2 Convolution Reverb

On Fri, 2011-01-14 at 21:29 +0100, Tom Szilagyi wrote:
> Hi all,
>
> after a day of intense work and testing, I present you a corrected
> version of IR. Version 1.1 contains these important fixes:
> * really use the user's homedir for storing the .ir_save file
> * proper GType and GThread initialization, at the proper place
> (loading of the plugin shared library)
> * fix ir.ttl: add missing namespace prefix "rdf"
> * fix usage of zita-convolver (proper stopping and deallocating of
> Convproc instances). Thank you Fons for checking out my code and
> instructing me.
> * fix crash when removing a never-unbypassed plugin instance
>
> There are two known issues with IR 1.1:
> * When a plugin instance is created bypassed in Ardour (for example
> when copy&pasting from another IR instance), you have to un-bypass the
> new instance to be able to configure it.
> * Removing a plugin instance from Ardour while the plugin is in the
> middle of a lengthy resampling operation (waveform display reads
> "Loading" or "Calculating") will crash. It is easy to avoid this;
> please do so. A fix for this is planned in a future version of IR.
>
> Regarding LV2 hosts other than Ardour: the second in the above list of
> fixes should help, however please be aware that IR is at the moment
> really not usable without its own GTK UI. In future versions I may
> manage to switch to using an external-process LV2 UI which would
> result in the plugin UI being completely host toolkit agnostic.

FWIW, I would not do this. The external UI extension is the wrong way
of going about this, and momentum towards it is very worrysome... We
need an abstraction layer (i.e. a library) to provide the ability for
any UI to be external. It shouldn't be the host's - and very definitely
not the plugin's - problem to do this. It's a difficult problem to get
just right(*). Even if it wasn't, we'd end up with the same code
implemented all over the place, which is an obvious sign something is
not right...

The right way is for the plugin UI to provide whatever native UI (e.g.
gtk) it pleases, and a library provides the means to launch it
externally if the host toolkit does not match. This way, the host can
embed the UI if possible (a feature which really is a shame to throw
away), but anyone can use it externally if this is not possible. It is
also possible these days for Gtk to embed Qt, and vice versa, which the
lib could also do... in short, all the tricky business of using an X UI
in a Y host, either embedded or externally, needs to be done in one
place, and done in that one place correctly, so every host/plugin author
doesn't have to repeatedly deal with the same problems.

After the upcoming LV2r4 (and new librdf-free slv2) is released (soon),
I will take a stab at making this library. All the nitty gritty has
been done by other people already, it just needs to be sanely
amalgamated.

-dr

(* and it has recently come up that it seems impossible to get certain
window related things right with the current scheme...)

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Feb 9 20:15:03 2011