LV2 Not All Being Recognized?

[joshs]

I'm starting to notice that Mixbus is very picky about what LV2 plugins it will load... Or maybe it's just not refreshing the list for some reason. But I installed klangfalter and x42 plugins (including convLV2). Klangfalter LV2 wouldn't show up (but the VST did) and convLV2 didn't show up even though it seems other x42 plugins did. By comparison Carla (a plugin host for Linux) doesn't have any trouble loading these.

[Domino]

If you open the error log window (click LED at top right corner of editor window) you should be able to see what plugins have been ignored and why..

[WARNING]: Ignoring LV2 plugin "KlangFalter" because its buffer-size requirements cannot be satisfied.
[WARNING]: Ignoring LV2 plugin "AT1" because its buffer-size requirements cannot be satisfied.
... + another 20 or so buffer-size issues

I don't know if there's a fix for these buffer-size issues, but would like one as I'd really like to use the lv2 version of AT1 in Mixbus.

IR is a convolution reverb that does work.

---

Looks like it's the plugins that need work to support variable buffer sizes:

https://github.com/DISTRHO/DISTRHO-Ports/issues/12

[joshs]

Ah, yup there it is. All of them ignored because of buffer size. I mentioned this on another thread. Hopefully Harrison will address this in 3.1...

[x42]

Mixbus can change the buffersize any-time and also splits the process-cycle for automation playback.
Some Plugins - especially convolution plugins - do not support this.

eg. the session runs at a period-size of 1024. But 377 samples into the cycle some parameter changes. So Mixbus processes 377 samples, then updates the plugin's control-ports and proceeds to processes the remaining 647 samples.
Also during export, Mixbus changes to use 4096 samples (to speed up the process). A user can also change the period-size at any time.

In the past this regularly lead to crashes, because some plugins assumed the period-size never changes. So Mixbus refuses to load plugins with
the property http://lv2plug.in/ns/ext/buf-size/#fixedBlockLength for now.

This issue is being worked on multiple sides. The following options are already available to plugins:

• LV2 already offers an alternative (Message control ports), the host can pass all automation for the complete cycle to the plugin and the cycle does not need to be split.
  
• Mixbus can notify a plugin if the buffer-size changes (if the plugin supports #nominalBlockLength callback)
  
• A new plugin property: "NoSampleAccurateControl" can tell the host to preferably not split the cycle for a given plugin (automation only, seamless looping etc will still require) This is not yet standardized, but working.
  

There are further plans to ameliorate the situation by moving come of the complexity into the plugin-host

• add support to Mixbus to re-initialize a plugin if the buffer-size changes. - This can result in glitches, or audible artifacts,.. esp for short temporary changes.
  
• add support to Mixbus to wrap the plugin. ie always add a large buffer to guarantee the blocksize requirement at expense of additional latency. This might better be done on the plugin-side since Mixbus cannot know how to best handle this for any given plugin, though
  

[Domino]

Thanks for taking the time to explain the issues and plans to resolve them.

[melodiousthump]

I've been having this issue and found this old thread while searching for solutions.

Any updates on the host-end plans over the past year?

Thanks!