/lv2vst

experimental LV2 to VST2.x wrapper

Primary LanguageCGNU General Public License v2.0GPL-2.0

LV2 - VST wrapper

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

QuickStart

On GNU/Linux:

git clone https://github.com/x42/lv2vst
cd lv2vst
make
mkdir -p ~/.vst/lv2vst
cp lv2vst.so ~/.vst/lv2vst/lv2vst.so

# this assume you have x42-plugins, specifically x42-eq installed
# or use `lv2ls` to find some LV2 URI/URI-prefixes.
echo "http://gareus.org/oss/lv2/fil4#mono" > ~/.vst/lv2vst/.whitelist
echo "http://gareus.org/oss/lv2/fil4#stereo" >> ~/.vst/lv2vst/.whitelist

Then launch a LinuxVST plugin host...

Description

lv2vst can be deployed in different variants:

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

Specifically:

  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.

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
  make XWIN=x86_64-w64-mingw32 clean all
  make XWIN=i686-w64-mingw32 clean all

Copy the resulting lv2vst.so 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.

Caveats

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 VST-shell.so 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.

A dedicated bundle or whitelist is generally preferable.

lv2vst can be used multiple-times in dedicated folders, each with specific whitelist to expose plugin-collections (lv2ls | grep URI-prefix > .../.whitelist).

YMMV