Percussa Home / Shop / Contact /

Docker-based workflow for VST cross compiling

SSP SDK
#1

EDIT: Instructions on how to set up a dev environment to build plugins for the SSP using this workflow further down the thread here.

There’s this project called Dockcross which provides a docker-based workflow for cross-compiling code for ARM on Mac/Windows. It mounts the current local directory inside a Docker container that runs Debian Stretch and has the toolchain set up in it and then runs the (build, or any other) command inside the container. It’s very easy to get up and running…

docker run --rm dockcross/linux-armv7 > ./dockcross-linux-armv7
chmod +x ./dockcross-linux-armv7
./dockcross-linux-armv7 bash -c '$CC hello.c -o hello_arm'
./hello_arm

I’ve successfully completed the “Hello World” example, but I’m a complete n00b at C(++) and not sure where to go from here. Would I have to install JUCE, Steinberg API and all the ARM dependencies in the docker container, or could they live in the local directory and then be compiled against when it runs?

Does this look useful? (As an aside, I’m getting some really annoying errors trying to set up the Debian Stretch Virtualbox environment, which is why I’m pursuing this route.)

I’ll keep plugging away at it.

#2

yes, you would need to install juce and steinberg api
be aware the ssp-sdk uses a particular version of juce. (which I would start with to avoid confusion)

then what Ive done is get libs and headers from the ssp itself - to ensure I end up with the correct versions.

does it look useful? possibly… the issue whichever way you go is making sure you set up an environment that compiles compatible binaries for the ssp … compiling for arm is part of that, but not the whole story, so I guess this gets you part of the way.

however… my suggession is… not to do this at first!

really Id recommend for your first vst to with the ‘path of least resistence’
for me, that was simply to follow @bert’s excellent post on how to setup a development environment.
Im pretty sure when I first did this. I followed this pretty much to the letter and ‘it just worked’ ™
I was quickly able to compile the test vst (qvca) and go from there.

this environment served me well, up until very recently.

the KEY thing with all development is just to get started writiing (and debugging) code,
do not try to ‘optimise’ your code/workflow until you are familar with the simple approach (KISS).

that said, the main thing I did early on was to figure out how I could build and run the ssp vsts on my mac.
this means that I only needed to use the ssp build environment for actually creating the binaries to send to the SSP … which was only a small part of the development effort.
(mainly at the end when the code was all written, and I needed to test it on the SSP itself)

the main ‘trick’ to that is exposing the encoders/buttons as vst parameters, which is pretty simple - you can see that in my VSTs on repo

note: you may want to go back to some of my very early commits - perhaps when I first released clds - as this shares much more in common with the ssp-sdk - and is simpler.

But I do prefer using a cross-compilation (over running a virtual host) , as its much faster to compile, and I can more easily use my normal tools.

that said, I created my own native cross compiling enviroment on my mac, which is based off homebrew plus some scripts that I created - I use this for bela, rPI, norns and now SSP.

I dont really have any documentation for it (except what is in the repo), but there is more general information on the bela forum, which is the platform I initially created it for
https://forum.bela.io/d/1251-cross-compilation-for-bela

this is not to say its ‘better’ than docker, but rather I wanted something that was running completely natively on the mac, not thru some intermediate layer.

the disadvantages…

  • I dont have time to support it for others, so consider it a starting point only
  • I use cmake as it has full support for cross compliation - if you aren’t using cmake for your projects will need to figure out how some extra things
  • using cmake for juce is a very new thing

the advantanges…

  • its all running native, using homebrew tools - which means I can run as native arm binaries on my mac mini m1, which means its blisteringly fast
  • I know all the tools, no magic :wink:
  • I can use all my tools directly

so basically my environment is…
I run CLion (for Apple Silicon) to compile and run my VSTs on natively on my , where I do most of the dev.
I then simply use cmake to compile on my mac, and scp the vst over to the ssp.

It took a quite a while to setup, but now is stupidly fast compared to when I was running a VM running debian stretch and compiling on that !

#3

whats the issue? lots of people use virtualbox so it should be fine…

that said, I tend to historically use either Parallels or Vmware Fusion.
Recently its been vmware fusion - though my move to a mac mini m1, means I cannot do that at the moment, which is why i pushed forward on the cross-compiling route.

#4

btw: whilst grabbing the bela forum link above to my xcBela stuff,
I noticed someone has ‘ported’ my xcBela stuff to Docker.

Ive not really looked into it,
https://forum.bela.io/d/1296-cross-compilation-in-a-docker-container

that said, Im not sure what advantages it brings…
they mention portability, so perhaps its just easer to run on mac/windows/linux
but ive not looked into it.

#5

Thanks for all the information! It will take me a while to digest it…

Yeah, the reason we’re here is that it didn’t “just workTM” :slight_smile: Creating the chroot errored out the first time and now won’t get past it because some file already exists. Something I could get past eventually, I’m sure.

The main advantage of Docker is that it’s spinning up a container using an image in a known state each time, and that can have everything you need already. (And yeah, this can be on Linux, Mac or Windows.) It’s possible I would find an image already set up for JUCE VST cross-compilation or something - or once you get one configured, it can be saved and shared.

I think you’ve got a huge point though, which is that I don’t even know how to compile a VST on Mac yet :smiley: If I catch up on that route, maybe it will give me perspective on how to approach the cross-compilation. Cheers.

EDIT: Will report back on this thread with instructions if I get further with Docker.

#6

probably worth a bit of googling, theres alot of info on chroot out there.

chroot, in many ways is quite similar to what docker is doing,
basically its creating an environment under your home directory.
the only thing you have to be aware of its that it is created as root, so to navigate around it (without entering chroot) is you have to swtich to root.

its kind of strange when you first use it, but actually its pretty simple.

basically docker,chroot, my method - all do something similar which is to just create an separate environment for things like /usr/include so you dont overwrite the host os :slight_smile:

the thing you will need to be careful with dockers, is you still need to create a debian stretch environment, since thats the correct libraries/headers if you use something later (e.g. buster) it could have the wrong library versions - this might not fail to build for you BUT when you come to run on the SSP its possibly going to have linked to the wrong version of runtime libraries

it all can be worked out and fixed, but when Im new to an environment, all I want to do is to quickly get the ‘test example’ running… as simply as possible.
… then I can get on with the real fun which is coding something new…

if I spend days trying to get that initial dev environment up, then that can be really frustrating!

yeah, after compiling QVCA and testing it runs on the SSP
my next task would be to build QVCA and run it on your mac.

it doesnt matter how effecient your cross-compilation environment is.
you are going to be very slow in dev, if you have to keep throwing the vst over to the ssp and restarting synthor every time you want to test a new features/bug fix.

this is why all the stuff I do is always cross-platform … I just find it much more efficient when doing ‘embedded’ type development.

Id say I spend probably ~90% of my time running on my mac, only 10% on the ssp - perhaps even less!

also has the advantage I can do alot of dev away from my ‘music room’ where my ssp is usally sitting.
(though these days Ive moved the SSP to a pod64x, so I can move it around easily enough :wink: )

#7

Got this going, and it’s pretty awesome. Don’t have to run a Linux VM at all, just develop on the Mac, then when ready, run one command and then SCP the plugin to the SSP.

Full instructions for Mac (should be very similar for Windows and Linux):

Prerequisites

Get sample repository

Download dependencies (one time setup)

  • git submodule init
  • git submodule update

Build Docker image for cross-compilation (one time setup)

  • docker build ssp-vst .
  • docker run --rm ssp-vst > dockcross
  • chmod +x dockcross
  • mv dockcross ~/bin/ or elsewhere on your PATH

Build plugin for SSP

  • dockcross bash -c 'cd plugins/scp/Builds/Linux && make CONFIG=Release'

SCP uhh… SCP plugin to SSP

  • scp plugins/scp/Builds/Linux/build/Debug/scp.so linaro@192.168.0.6:/media/linaro/SYNTHOR/plugins

EDIT: The Docker image is your build VM, and the dockcross script runs the build command in that container. So if you need any dependencies you can install them in the Dockerfile in the repo, which extends the Dockcross one. If you do this, you will have to run docker build ssp-vst . in the directory with the Dockerfile again to make the new image available.

2 Likes