[LV2] Fixed Buffersize Extension Question
d at drobilla.net
Sat Jan 26 14:18:08 PST 2013
On Sat, 2013-01-26 at 22:21 +0100, Georg Holzmann wrote:
> Hallo list!
> I am developing an LV2 plugin which requires a fixed buffersize (because
> of many internal buffers, which are not so easy to rewrite).
> So I tried the buffer size extension:
> However, does this mean, that any host which doesn't support this
> extension won't be able to load the plugin?
> At least I was not able to load it anymore ...
> If yes, which hosts support this extension already?
If you list a feature as required, then yes, the host may not load the
plugin. That is the point of a required feature, really, if the plugin
*requires* a feature, then it can not work when the feature is present.
You can also list a feature as optional, which lets the host know the
plugin supports it, but the plugin can fall back and work correctly
without the feature available.
> Or is there any other way to get something similar, without breaking
> compatibility with all simple LV2 hosts?
> I guess most of the hosts use a constant buffersize also if they don't
> support this extension?
The feature is relatively new, so it is not very widely supported. It
is (mostly kinda sorta) supported inherently by anything that runs
plugins directly on Jack buffers, but it's tricky for hosts that split
cycles for timing reasons.
It sounds like all you actually need is *maximum* block length? This is
much simpler to support, virtually all hosts should be able to (*fixed*
block length is difficult and controversial). I know that Jalv, Ardour
3, and Ingen currently do, not sure about others. Implementing it is
a simple matter of passing the required information to the plugins
instantiate method, so adding support should be easy.
I recommend relying on maxBlockLength if you need it, and encouraging
hosts to implement support. It is crucial information for many things.
If you really do need fixed, this will probably limit the number of
hosts that will support your plugin quite a bit, at least for the time
 We really need a compatibility matrix...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: This is a digitally signed message part
More information about the Devel