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
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.
- 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
- 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
- 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 !