How to build modules (VST plugins) for the SSP

Since the update Update 30072018 [VST Support + QuadVCA VST Plugin + BitCrusher + Module Picker] the SSP’s software supports Linux (ARM) VST plugins.

Please read the above update first as well as the info in this thread - LAN Port? - which explains which USB ethernet adapter you can use with the SSP (to copy files from/to it via scp) and how to get access the SSP’s serial console (which you can use to configure networking).

Once you have gained access to the serial console and have set up the SSP on your network and are able to SSH into it and copy files to/from it using scp (secure copy), you should set up your development environment. This is what you need:

  1. A development PC or Mac with debian stretch - either installed directly on the machine or in a virtual machine (virtualbox, vmware player, etc) that runs on your machine. I use virtualbox on a Windows 10 PC. You can find info online on how to install debian stretch in a virtual machine, or how to download a ready-to-use virtual machine.

  2. A chroot in your debian stretch to keep all your armhf stuff in - Below it will become clear you need armhf versions of linux libraries to build software. You can choose to install these libraries in a seperate folder on your development machine, and you can then refer to this folder for includes (-I) and libraries (-L) when you compile software, or, you can do what I did, which is to create a debian stretch chroot, in which you keep all your code, as well as the JUCE toolkit and armhf versions of libraries it needs and which you will have to install via apt-get. You can find info online on how to create a chroot and how to login to it.

  3. A toolchain to compile code for armhf (ARM hard float). The prefix for the toolchain is arm-linux-gnueabihf- … so the typical compilers you use on linux, such as gcc, g++ as well as other tools in the toolchain have this prefix. You can install this via the typical apt-get package manager on debian. You will have to install this in your chroot if you are using that.

  4. Our example VST plugin source code - We provide an open source code example to build a VST plugin (module) for the SSP. You can find the source code here - - you can check out the code via git on your development computer. You will have to do this in the chroot if you are using that.

  5. The JUCE toolkit - We use v3.1.1 of JUCE to build our software and branched off at - you can check out this commit directly using git so you use the exact same version as we use, or you can use the latest JUCE version. You will need JUCE to build our VST plugin example. Of course, you can also build your VST plugin any other way you want, and use something else than JUCE to do it. If you check out the JUCE code, make sure to do that in the chroot (if that is what you’re using).

  6. armhf versions of the libraries JUCE needs - JUCE depends on a bunch of libraries on linux, so you need those libraries, but the armhf versions (ARM hard float) and not the intel versions installed on your development computer. You can find the list of libraries here - If you are using a chroot this step is pretty easy as using apt-get in the chroot will download automatically the armhf versions (as long as you’ve configured your package manager to download the armhf versions first, of course).

Once you managed to compile the VST plugin example (QVCA)

The code example we provided has a and script in Builds/Linux which helps you build the software. You can do

./ Release

and then

./ Release 6

which will then copy the compiled VST plugin to the SSP via scp (using IP address which is what the SSP is by default configured as - this depends on how you configured networking on the SSP). Of course you can also build a Debug version of the plugin in which case you replace Release with Debug.

Keep in mind that you will have to stop the SYNTHOR service on the SSP, and restart it, or your VST plugin won’t be found. The software scans the plugins folder on the SD card when it starts and does this only once. So SSH into the SSP over your network and do this -

sudo service synthor stop 
sudo service synthor restart

Debugging on the SSP

If you want to use gdb to debug your plugin on the SSP, you first stop the synthor service, you then start the xserver in the background and then execute the software from within gdb. Keep in mind that your plugin has to be compiled using Debug, and not Release, or you won’t get any info when it crashes in gdb.

sudo service synthor stop
sudo startx & 
gdb /media/linaro/SYNTHOR/SYNTHOR 

then once you are in gdb use ‘r’ to run the program. Use CTRL-C to stop the program and ‘q’ to quit gdb. If you then want to stop the xserver you use the ‘fg’ command on the command line to bring the xserver to the foreground. You can then use CTRL-C to stop it.


The above should help you get started as a developer. The explanation is pretty high level and assumes you are already familiar with linux and the command line, and how to install packages. If you have specific questions on any parts of this process please comment below and I’ll do my best to help.



does this mean developers have to build & install every time you provide a new SYNTHOR file?
just copy a .dll and / or exe to a VST folder (after compile) would seam more user friendly

No, the VST support is built into our software now, so developers can independently work on their modules and release them and we will be able to load them. We are not dependent on each other. That is the advantage of using the VST standard.

1 Like

Wonder will ever popup a super special developer who can do this ? :wink::stuck_out_tongue_closed_eyes:

1 Like

It’s on my list to attempt to recompile some mod duo, lv2 and other similiar plugins for the SSP. No specific timeframe in mind though. The list is long and the day is short. Patience!


from this week i have a debian distro + JUCE toolkit working

how do i load the exemple VST into JUCE?

just copy the ZIP and extract into a project folder and then load/open ?

or are there more differentiated steps to take?

since JUCE is a cross platform application, is there restraining us something to develop in JUCE on Windows and then (re)compiling on a LINUX arm hf?

Yes it is possible to target multiple architectures.

JUCE is not an application but a toolkit, which is basically a collection of source code files. You use a C++ compiler to turn the source code into an executable. On windows you use vistual C++ express for example, which is a development environment including a compiler for intel / windows.

so yes, you can develop an audio plugin (VST) on windows using JUCE and visual c++ express for example. JUCE comes with a “wizard” to generate a basic plugin, this tool is called the projucer or introjucer. You first need to compile this tool from source code included in the JUCE source tree. There is already a visual studio project in the tree that you can load in visual studio or visual C++ express.

but besides all this, I already provided instructions in the forum on setting up a development environment as well as a link to the QVCA project / example VST plugin I created using JUCE, so you really don’t need to go through all this on windows unless you really want to.

1 Like

you don’t load the VST example into JUCE, you compile the example using a compiler, for example on linux / arm you use the gcc/g++ (GNU) compilers for ARM and make tools. In the example I provided a Makefile and build script to build the example.

The example assumes you have the JUCE code tree installed relative to it (look at the Makefile and source code of the example), so it can find it during compilation.

The result of the compilation is a VST plugin (= a shared library, on windows this would have the extension .dll but on linux it’s .so). Your VST host (our software on the SSP) can “load” this shared library at run-time.

1 Like

all is clear, for the moment

i followed your instructions but feel more at home in a windows environment (JUCE+VS2017), the debian stretch JUCE is working, but still it is a contained environment (virtual box) which isn’t as fluid working as i would like

I was able to find some good results by searching the web for “cross compiling to raspberry pi from visual studio”.

That being said, if you can get comfortable with linux, you might eventually find it is more direct to work on a similar platform to your target. Or not. YMMV.


I prefer Windows as well, although I love Linux. My solution was just a debian VM as Bert suggested. Trust me, once you’ve figured it out, and can literally get the SSP to do whatever you can imagine, it’ll be worth it.

I’ve been dragging my feet, but I should have something to share with you all in a little bit.

1 Like

microsoft has been working on supporting ARM compilers in visual studio and when that happens it will become easier to build directly from windows without needing a virtual machine with linux.

however you will still need to have the ARM versions of packages that JUCE depends on. For example freetype2, which is used for font rendering in JUCE. So that is why I suggest to use a linux (debian) virtual machine and build everything in there because you can easily install all the packages you need to compile your project.


or send my developed VST to someone with an ARM distribution for compilation? (hint)

you have to be able to compile your own code and debug it, there is no way around that.

1 Like

Right. One hopes that code written for one architecture will compile correctly on the first try when targeting a new architecture, but there are many reasons why that might not be the case, and at that point, you find yourself in a debugging loop. It would be far too inefficient to do this debugging in any way other than on your own local setup.

1 Like

I would really like to get involved in this programming but I’m sure I would need some help. Is anyone working this via github or other chat channels?