[LV2] LV2 best practices

Robin Gareus robin at gareus.org
Wed Aug 1 14:22:22 PDT 2012


Hi,

I am working on a set of LV2 plugins related to B3 organ synth and have
a few questions regarding best practices for LV2 plugins.


1) "advanced mode" - imagine plugin that has a couple of settings that
are usually fixed (e.g. speed of sound though air). Advanced users may
want to tweak them, and some users may want to abuse them, but both are
edge-cases. Further assume that said plugin has <= 3 "normal" control
ports, but >= 20 "advanced" settings.

  * How to best expose the "advanced" settings?

I thinking about one of the following:
a) two plugins (one with all controls, one with only common controls)
b) include a custom GUI and hide advanced settings.
c) use http://lv2plug.in/ns/ext/port-props/#displayPriority

Any other alternatives? What is the recommended way?


2) "static configuration". Assume a plugin has static configuration that
can only be set on initialization and can not be changed later (e.g. the
temperament of a synth). I can not see a good way how to deal with that.

  * How can one set up an initial persistent state?

Shall that be avoided? IOW Must a plugin only have parameters that can
be modified at runtime and must not include persistent configuration?

Some thoughts:
It might be possible to re-init the whole plugin using a port marked as
  http://lv2plug.in/ns/ext/port-props/#expensive
but if re-initialization requires memory allocation it must not be done
from a RT-callback. A dedicated (non-rt) helper thread could be spawned
to take care of re-init and the plugin remain silent until re-init is
complete. Dirty hack or what? :)

Abusing the state-interface may be another possibility to get the job
done.. -- can a plugin ask the host to re-initialize a plugin instance?

  * How to best implement plugin re-initialization that is triggered by
changing an /expensive/ control value?


Thanks in advance,
robin


More information about the Devel mailing list