Creating modules for the SSP ( aka ssp-sdk updated !)

Important Note: this assumes you have the LATEST SSP firmware on your SSP

I’ve noticed that many of the topics in this category are very much outdated, this topics covers updated information.

Percussa SSP SDK

Where to get the SSP SDK?

SSP SDK

This includes a readme, which will also serve to get you started.

most important steps are:

Setting up development environment

Creating a development environment

Building ssp-examples

Building examples


Background

This is all covered in the main documents, but to give some general information.

The development model followed here is a ‘cross-compilation’ model. ( * )
This means rather than compiling on the SSP, or under a virtual environment that looks like the SSP, we compile natively on our desktop - this approach is MUCH faster.

This approach also supports cross platform development, allowing users to test on their desktop.
(beyond the scope of this topic :wink: )

( * ) e.g. your desktop might be intel binaries, but the SSP requires arm binaries.

we use a few build tools to help us to this:
cmake - a modern build system
clang and gcc - with its cross-compiler support.
buildroot sdk - this contains the libraries and headers the SSP uses, and were released in this topic

linux distros have cmake, clang and gcc all natively available via their package managers (apt/pacman etc).
macOS does not really have this natively, as its not generally a dev platform, so we use home-brew to provide a package manager, which has access to these tools.

windows is very different… you could modify the cmake system to use it natively.
but frankly, its much easier to install a linux vm, and then follow the linux route.
as linux is a much more ‘developer’ friendly environment - your choice however :wink:

3 Likes

useful resources

general

for juce/vst only (not a requirement !)

1 Like

Alternatives

RNBO

using the Percussa SSP SDK to create modules requires knowledge of dsp, c++ and a variety of other skills. my RNBO project allows non-developers to create modules for the ssp.

forum post - https://forum.percussa.com/t/max-rnbo-template-user-created-modules
release - https://github.com/thetechnobear/rnbo.example.ssp

2 Likes

I saw you mention somewhere you are primarily doing this development on an m1 Mac. I am trying to setup the same. How are you running Debian? Is this on a VM or on a raspi? I do have a raspi sitting around that could use some work. If on a VM, what are you using to run on the m1? I had an unsuccessful run with VirtualBox so far.

This runs natively on the mac , no need for Linux/VM , it’s all in my docs.

Ah sorry, got confused with the linux bit at the top for some reason.

I have gone through the setup doc but when I try to build the example, I get the following output. Is there a library I’m missing?

/opt/homebrew/bin/arm-linux-gnueabihf-ld: cannot find Scrt1.o: No such file or directory
/opt/homebrew/bin/arm-linux-gnueabihf-ld: cannot find crti.o: No such file or directory
/opt/homebrew/bin/arm-linux-gnueabihf-ld: cannot find crtbeginS.o: No such file or directory
/opt/homebrew/bin/arm-linux-gnueabihf-ld: cannot find -lgcc: No such file or directory
/opt/homebrew/bin/arm-linux-gnueabihf-ld: cannot find -lgcc_s: No such file or directory
/opt/homebrew/bin/arm-linux-gnueabihf-ld: cannot find -lc: No such file or directory
/opt/homebrew/bin/arm-linux-gnueabihf-ld: cannot find -lgcc: No such file or directory
/opt/homebrew/bin/arm-linux-gnueabihf-ld: cannot find -lgcc_s: No such file or directory
/opt/homebrew/bin/arm-linux-gnueabihf-ld: cannot find crtendS.o: No such file or directory
/opt/homebrew/bin/arm-linux-gnueabihf-ld: cannot find crtn.o: No such file or directory

I had been working on creating an updated Docker template for this and got it most of the way there other than cmake wasn’t on the path. One thing I noticed on that journey that isn’t in these newer docs is the juce setup. Since the example is in juce, are there some extra steps compared to RNBO?

is this when it tries to test build, or actually tries to build a module…

I need more of the log… so I get some context :wink:

it looks like probably when building the modules, in which case, Id say you have not got your buildroot in the right place… (see examples in instructions)
I’d recommend you setup exactly as-is with defaults initially, so you dont need exports etc, then once you are familiar with setup… you can start overriding things.

I know keeping defaults works, as I did a fresh install on an m2 following these instructions, and @Handsonicsuki did the same for an intel Mac.


juce - again, follow the install instructions.

IGNORE previous instructions, they are ALL completely redundant.
the new ones are completely self-contained.

you do not need to install juce separately its all done for you.

cmake not on path, again, its in the instructions… its says add homebrew to your path.


docker, whatever ,I personally dont like docker much nor use it.
so I cannot support it.

Thanks looking earlier in the errors made me notice something strange about buildroot. I did have to manually specify that and the path was just slightly different from the example provided. Default for buildroot seems to be $HOME/buildroot/output/host when nothing is specified.

I do have solid professional development experience, but not much in the way of C++. The build tool chain has been a bit of a mystery to me. But I have worked across a variety of different languages and tool chains. Sorry if I am asking stupid questions.

1 Like

Now have things compiling and looks good. Thanks for all your effort in documenting this. Seeing that documentation existed and it wasn’t just the original developers contributing was a big part of what drew me to the SSP.

1 Like

cool, glad you got it working…

yeah, setting up cross compilation environments, can be pretty tricky, with a set of tools many are a bit unfamiliar with. this one is based on one Ive been using for the SSP for quite a while now (and similar to one I use for other projects too ( * )

anyway good news is… I tend to find, once you have a working environment, it’s much easier to ‘tweak it’.
so now your up n’ running you should be good to go.

hopefully you can now focus on the coding side… much more exciting than creating build environments :slight_smile:

( * ) - hence the ‘xcSSP.cmake’, as I have different ones for different targets)