Difference between revisions of "How To Build and Deploy LV2 Plugin to MOD Duo"

From MOD Wiki
Jump to navigation Jump to search
Line 1: Line 1:
 
== Introduction ==
 
== Introduction ==
  
This is a quick start guide to get a LV2 plugin running in a MOD Duo Device.
+
This is a quick start guide to get an LV2 plugin running in a MOD Duo device.
 
Let's cut the chatter and get started.
 
Let's cut the chatter and get started.
  
Line 8: Line 8:
 
This information is well described elsewhere.
 
This information is well described elsewhere.
  
* [http://www.nongnu.org/ll-plugins/lv2pftci/ LV2 programming for the complete idiot]
+
* [[Creating_Plugins]]
 
* [http://lv2plug.in/book/ LV2 Book]
 
* [http://lv2plug.in/book/ LV2 Book]
 
* [http://harryhaaren.blogspot.com/2012/06/writing-lv2-plugins-lv2-overview.html Writing Lv2 plugins : An Lv2 Overview]
 
* [http://harryhaaren.blogspot.com/2012/06/writing-lv2-plugins-lv2-overview.html Writing Lv2 plugins : An Lv2 Overview]
Line 14: Line 14:
 
== Prepare build tools ==
 
== 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.
+
In order to run a plugin in the MOD Duo we must compiled it for its specific architecture.
MOD Duo for example uses an ARM processor running a special flavor of Linux containing a specific set of libraries (dependencies).
+
The Duo uses an ARMv7 processor running a very basic and stripped-down version of Linux.
 +
Several audio-related libraries are included (fftw, libsndfile, libresample, etc) as well as generic libraries (boost, eigen, qt5core, etc).
 +
 
 +
We currently provide a custom build system that gives developers a similar system to what's available inside the Duo.
 +
(Using a regular Linux system might lead to issues due to mismatching library versions.)
  
We currently provide a custom cross-compiler that will take care of building LV2 plugins that will run in a MOD Duo.
 
 
Just clone [https://github.com/moddevices/mod-plugin-builder MOD Plugin Builder] and follow the [https://github.com/moddevices/mod-plugin-builder/blob/master/README.md instructions].
 
Just clone [https://github.com/moddevices/mod-plugin-builder MOD Plugin Builder] and follow the [https://github.com/moddevices/mod-plugin-builder/blob/master/README.md instructions].
  
Line 24: Line 27:
 
<source lang="console">
 
<source lang="console">
 
$ cd
 
$ cd
$ git clone https://github.com/moddevices/mod-plugin-builder
+
$ git clone git://github.com/moddevices/mod-plugin-builder
 
$ ./bootstrap.sh
 
$ ./bootstrap.sh
 
</source>
 
</source>
  
Once the process is finished you should have local binary called <code>build</code>.
+
Once that process is finished you'll be able to build plugins.
  
 
== Get source code and create a .mk file ==
 
== Get source code and create a .mk file ==

Revision as of 14:05, 24 May 2016

Introduction

This is a quick start guide to get an LV2 plugin running in a MOD Duo device. Let's cut the chatter and get started.

LV2 Basics

This information is well described elsewhere.

Prepare build tools

In order to run a plugin in the MOD Duo we must compiled it for its specific architecture. The Duo uses an ARMv7 processor running a very basic and stripped-down version of Linux. Several audio-related libraries are included (fftw, libsndfile, libresample, etc) as well as generic libraries (boost, eigen, qt5core, etc).

We currently provide a custom build system that gives developers a similar system to what's available inside the Duo. (Using a regular Linux system might lead to issues due to mismatching library versions.)

Just clone MOD Plugin Builder and follow the instructions.

In summary:

$ cd
$ git clone git://github.com/moddevices/mod-plugin-builder
$ ./bootstrap.sh

Once that process is finished you'll be able to build plugins.

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/

I suggest you take a look at sections #Few things about Buildroot and #Alternatives to retrieve source code for more information.

Compile it

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.

Deploy it

Coming soon...


Publish it

Coming soon...


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

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)

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. You can find a working example of such setup here.

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.