Skip to content
experimental LV2 to VST2.x wrapper
C C++ Other
Branch: master
Clone or download
x42 Keep LV2 UIs and their dependent libs mapped
This works around an issue with supercollider's VST host and
dynamically linked plugins using libs with static initialization.
(e.g. pango font-cache, or gobject)
Latest commit e5b1716 Sep 2, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
include Add support for sending SysEx messages Jul 31, 2019
lib version zero Jun 4, 2018
misc version zero Jun 4, 2018
src Keep LV2 UIs and their dependent libs mapped Sep 2, 2019
.gitignore version zero Jun 4, 2018
COPYING version zero Jun 4, 2018
Makefile Add option to not unload LV2 binaries Sep 2, 2019 Clarify readme, document multiple whitelist mode Aug 21, 2019 version zero Jun 4, 2018

LV2 - VST wrapper

Expose LV2 plugins as VST2 plugins to a VST plugin-host on Windows, OSX and Linux.


On GNU/Linux:

git clone
cd lv2vst
mkdir -p ~/.vst/lv2vst
cp ~/.vst/lv2vst/

# this assume you have x42-plugins, specifically x42-eq installed
# or use `lv2ls` to find some LV2 URI/URI-prefixes.
echo "" > ~/.vst/lv2vst/.whitelist
echo "" >> ~/.vst/lv2vst/.whitelist

Then launch a LinuxVST plugin host...


lv2vst can be deployed in different variants:

  • wrap dedicated LV2 bundle(s), compile-time specified.
  • wrap any/all LV2 Plugins(s), runtime lookup

The first is intended for plugin-authors: A LV2 plugin can be seamlessly distributed as VST2.

The second approach is useful for users who want to use existing LV2s in a VST plugin-host.


  1. If a .bundle file exists in the same dir as the VST, only load lv2 bundle(s) specified in the file (dirs relative to lv2vst.dll, one per line). A list of bundles can alternatively be specified at compile-time and hard-coded.

otherwise use system-wide LV2 world:

  1. Load .whitelist and .blacklist files if they exist in the same dir as the VST (one URI per line).

    If the whitelist file exists and contains a single complete URI (one line), no VST-shell is used and a single plugin is exposed.

    Otherwise index all plugins (alike lv2ls), expose only plugins which URI matches a prefix in the whitelist. If no whitelist files is present (or if it's empty), consider all system-wide LV2 plugins.

    Next the .blacklist file is tested, if a Plugin-URI matches a prefix specified in the blacklist, it is skipped.

The CRC32 of the LV2 URI is used as VST-ID.

LV2VST does not bridge CPU architectures. The LV2 plugins and LV2VST architectures and ABIs need to match.

A dedicated bundle (1), or dedicated whitelist (2) is preferred over blacklisting.

Supported LV2 Features

  • LV2:ui, native UI only: X11UI on Linux, CocoaUI on OSX and WindowsUI on Windows.
  • LV2 Atom ports (currently at most only 1 atom in, 1 atom output)
    • MIDI I/O.
    • plugin to GUI communication
    • LV2 Time/Position
  • LV2 URI map
  • LV2 Worker thread extension
  • LV2 State extension
  • Latency reporting (port property)

Build and Install

Compiling lv2vst requires gnu-make and the GNU c/c++-compiler. Windows (.dll) versions are to be cross-compiled on GNU/Linux using mingw.

  make XWIN=x86_64-w64-mingw32 clean all
  make XWIN=i686-w64-mingw32 clean all

Copy the resulting lv2vst.dll into a folder where the VST host finds it. For macOS/OSX, a .vst bundle folder needs to be created, with the plugin in Contents/MacOS/, see make osxbundle.

lv2vst can be used multiple-times in dedicated folders, each with specific whitelist to expose plugin-collections. e.g.

	mkdir -p ~/.vst/plugin-A/
	mkdir -p ~/.vst/plugin-B/
	cp ~/.vst/plugin-A/
	cp ~/.vst/plugin-B/
	lv2ls | grep URI-A-prefix > ~/.vst/plugin-A/.whitelist
	lv2ls | grep URI-B-prefix > ~/.vst/plugin-B/.whitelist


Various LV2 plugins are known to cause crashes.

LV2VST first indexes all plugins to be collected into a single VST-shell. This step is generally safe (using only lv2 ttl meta-data). The LV2 description is validated and VST-IDs (CRC32 of the LV2-URI) are generated.

When the host scans the actual plugins, lv2vst instantiates the mapped LV2. This is to ensure that the actual plugin will load later. A single will load (and unload/destroy) various LV2 plugins (and their dependent libs, if any) in the same memory-space.

This is known to cause problems with some sub-standard LV2 plugins, e.g. some use static init, fini methods, others use custom threads which are not terminated (or the plugin does not wait for threads to terminate: crash on unload). Yet others use static globals or expose all their symbols in the global namespace (possibly conflicting names) and/or mix libaries which do so.

Most of these plugins will also cause crashes in other LV2 hosts. Except that LV2 hosts don't generally instantiate a plugin unless it is used.

Hence it is preferred to expose only specific plugins that are known to work reliably, using a whitelist.


You can’t perform that action at this time.