On 10/20/2012 03:27 PM, Tom Szilagyi wrote:
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.
indeed. Thanks a bunch for your effort.
> I'd just like to note that the "inherent requirements" such a
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
Luckily, drobilla uses the opportunity to start addressing some of the
shortcomings and there may be more down the road.
> after considerable
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
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.
Linux-audio-dev mailing list