[LAD] ANN: convoLV2 0.2

Robin Gareus robin at gareus.org
Sat Oct 20 17:45:36 UTC 2012

On 10/20/2012 03:27 PM, Tom Szilagyi wrote:
> On 20 October 2012 06:14, David Robillard <d at drobilla.net> wrote:
>> We hope that convoLV2 will eventually be as fully-featured as IR.lv2
>> without resorting to kludges that violate the LV2 specification.
> I'm accepting patches to IR if anyone cares to implement the features
> now seemingly made possible by LV2 so as to avoid any "kludges". 

Tom. I had a look the IR.LV2 code and before setting out on this one and
wanted to patch IR.LV2 but that turned into a rewrite. The three main
reasons for that are
 1) IR.LV2 does buffering to align small block-sizes to an internal
block, thereby introducing latency.
 2) IR.LV2 shares an instance pointer with the GUI
 3) IR.LV2 spawns its own threads (for loading and processing IRs and
also inside libzita-convolver). The threading seems to be responsible
for most of the crashes of IR.LV2 that I experience)

(1) could be dealt with, but (2) and (3) are a big NO in LV2. Changing
IR.LV2 to uses Atom-messages and use the worker-thread model requires a
major re-design of IR.LV2. Patches are not suitable to address that.

> I'm
> sorry that I had to violate(?) your LV2 specs in order to be able to
> produce a working plugin - one that was actually usable, back in
> January 2011 and ever since, by actual audio engineers using Ardour.

indeed. Thanks a bunch for your effort.

> I'd just like to note that the "inherent requirements" such a
> convolving plugin poses, that you are now addressing with convoLV2
> (maximum block length to be known in advance; power-of-2 buffer size),
> have been raised by myself as questions and requests for features on
> the LV2 mailing list sometime in early 2011,

LV2 is moving slowly but steadily. I had the same experience. different
topics. In particular static init arguments:

My intent is not to write a IR.LV2 competitor, but a LV2 convolution
plugin without GUI at all (to be used in setBfree). I want to pass
parameters to the plugin on startup and never change them again later
(much like jconvolver). It turned out this is not possible with LV2 - at
least at this point in time. Also, since there are no dynamic ports in
LV2, the very flexible channel mapping of convoLV2 needs to be
effectively hard-coded.

Luckily, drobilla uses the opportunity to start addressing some of the
shortcomings and there may be more down the road.

> after considerable
> frustration I had with LV2 while implementing IR. I'm quite happy that
> LV2 is finally getting there, but I'm afraid that I have lost all
> appetite for the sight of any LV2 specs 

If I may say so, the specs have evolved and quite a lot and are getting
nicer and nicer every day.

> so it is very unlikely that I
> will be implementing any un-kludging, spec-un-violating changes
> myself.

If that is the case, maybe you can consider helping up getting convoLV2
on its way. Since my intent to make convoLV2 a GUI-less plugin does not
seem to work out, there'll be need for a GUI at some point in time. On
this end there will be overlap with IR.LV2.


More information about the Linux-audio-dev mailing list