-
Notifications
You must be signed in to change notification settings - Fork 5
Development
The Percussa allows for 3rd parties to develop modules for the SSP using the SSP-SDK.
note: this may be outdated, need reviewing !
- Github repo containing SDK
- SSP SDK Subforum
- Setting up a development environment
- How to build plugins
- SSP / XMX is arm-based, so modules need to be compiled for ARM... so intel etc will not work.
- SSP has a hardware interface, so if you are trying to port open source VST code, its not going to support this so VSTs will need some 'adaptation'
- The above resources, will only help you setup a development environment for building plugins, it will NOT teach you how to code plugins (see below)
the following is a list of skills you (likely) need to create plugins for the SSP (actually for any platform)
- understand of how to create VSTs
- DSP
- C++/C
- build systems (cmake/make)
- Linux (to build and get around)
- Git (since you are going to want to store your code somewhere)
- SSK SDK
- Buildroot SDK for SSP/XMX
- Juce and/or VST SDK (optional)
In past SSP modules had to be VST plugins, and the easy way to create these was to use JUCE. however, since 2022, this has changed. Now modules must be implemented using the SSP SDK, and this has no dependancy on JUCE.
however, it is still possible to use the VST / Juce route, and can be productive route, as it allows for cross platform development..
The easiest way to get started to code plugins is to use JUCE, it is very powerful, cross-platform and also has a great forum for support from the community. see https://juce.com
Note: Juce is NOT completely free ! please checkout the licensing for complete details here
basically you have two choices:
- GPL - use for free, but make your code GPL - this means you MUST publish your source code
- Buy a JUCE license - then you do NOT have to publish your source code.
if you choose to use the GPL (Free) route, make sure you understand the implications eg. only using other code that are GPL compliant. its beyond the scope here, to cover all these details.
It may be useful to understand how the SSP firmware/OS has changed over time, and also the move away from VST hosting to a custom SDK, see devhistory