How To Build and Deploy LV2 Plugin to MOD Duo
This is a quick start guide to get a LV2 plugin running in a MOD Duo Device. Let's cut the chatter and get started.
This information is well described elsewhere.
Prepare build tools
A LV2 plugin is just a binary plus a TTL file. In order to run in a MOD Device it must be compiled using a cross-compiler targeting our hardware and software. MOD Duo for example uses an ARM processor running a special flavor of Linux containing a specific set of libraries (dependencies).
$ cd $ git clone https://github.com/moddevices/mod-plugin-builder $ ./bootstrap.sh
Once the process is finished you should have local binary called
Get source code and create a .mk file
If you have an existing LV2 Plugin you just need to create a makefile to build it. In case you haven't started your LV2 plugin yet just follow through the links above from #LV2 Basics.
We have a few samples available here. For this guide we'll use the eg-amp.lv2 example.
The build script is based on Buildroot which requires you to create a new package under
plugins/package/ and add a make file
<package-name>.mk. To learn more about how Buildroot works check the manual.
In our example you must do this:
$ cd $ git clone git://github.com/moddevices/mod-lv2-examples $ cp -R mod-lv2-examples/package/eg-amp-lv2 mod-plugin-builder/plugins/package/
We're all set to compile.
$ cd ~/mod-plugin-builder/ $ ./build eg-amp-lv2 $ ls ~/mod-workdir/plugins/ eg-amp.lv2
Success, the plugin has been built.
Few things about the build script and Buildroot
Buildroot is based on packages to build things. An LV2 plugin becomes a package and because of that it must comply with Buildroot rules.
A few important notes:
- The package name is defined by the folder name and cannot contain '.'
- There must be a <packagename>.mk file inside the package folder
- Inside the .mk file all defined variables must start with the package name replacing '-' with '_'
- Browse through other examples so you get an idea of other variations of the makefiles (how to use waf for example)
- If your code has dependencies you need to fill in the _BUNDLES variable with a list; you can check the available packages here
Alternatives to retrieve source code
The .mk file will define how your source code is retrieved. In the eg-amp example the .mk file tells Buildroot to download it from github. Alternatively you can use a local tarball or point directly to the source code.
Point directly to the source code
Just replace the top section called 'download source code' with the following:
<PACKAGE_NAME>_SITE_METHOD = local <PACKAGE_NAME>_SITE = /path/to/source
If you place the source code in same folder as the .mk file you can set the _SITE using
$($(PKG)_PKGDIR)/ as a relative path.
It's important that you replace the section, a _VERSION variable cannot exist or it will fail. If you try changing the eg-amp example don't forget to remove the trailing path from the make command. It should look like this:
<PACKAGE_NAME>_TARGET_MAKE = $(TARGET_MAKE_ENV) $(TARGET_CONFIGURE_OPTS) $(MAKE) -C $(@D)
Point to a local tarball
Assuming you make a tar.gz file and put it in the same folder as the .mk file then you must replace the top section called 'download source code' with the following:
<PACKAGE_NAME>_VERSION = 1.0 <PACKAGE_NAME>_SITE_METHOD = file <PACKAGE_NAME>_SITE = $($(PKG)_PKGDIR) <PACKAGE_NAME>_SOURCE = eg-amp-$(<PACKAGE_NAME>_VERSION).tar.gz
If you want to use an arbitrary path just replace the _SITE variable.