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:
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.
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.
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.
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 - https://github.com/percussa/ssp-sdk - 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.
The JUCE toolkit - We use v3.1.1 of JUCE to build our software and branched off at https://github.com/WeAreROLI/JUCE/commit/8b3935f12154767d37c65c1612d1bfeb93a5965f - 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).
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 - https://forum.juce.com/t/list-of-juce-dependencies-under-linux/15121. 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)
./install.sh Release 6
which will then copy the compiled VST plugin to the SSP via scp (using IP address 192.168.0.6 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.