Starting VST Development - Sharing Resources

Hello all. I’m setting up a C++ dev environment to start tinkering with SSP VSTs and wanted to just share my notes as I go, hopefully it helps or inspires others to try coding. Here’s a compilation of all the relevant links I could find on the forum so far talking about VST development for reference.

I compiled it and downloaded Visual Studio Community edition 2019 yesterday with all the C++ supporting packs I could find on the installer wizard. I hope to go through the walkthrough Bert has posted on the forum this weekend. I’ve got background in computer engineering and electrical engineering so I’m hip to concepts but currently out of practice with code. Environment errors always trip me up more than actual coding errors.


What IDE do you develop C++ in?
Should I do everything in a Linux environment or can I code/debug/build things on Windows using appropriate compilers?
Was i2c ever enabled in the Device list as was mentioned in a past forum thread?
Would it be helpful to create a library of “pseudo hardware inputs” like button presses or knob turning? That way I could run through a series of test in software before actually having to turn the knobs myself on the SSP?

" fakeSSP.button.on() " being passed to the VST and having it respond accordingly… dunno just thinking out loud, I don’t know if this would be possible or useful, but if you’ve got an idea of how you’d do this, I’d love to see a bullet point list of tasks to follow

I actually don’t have access to my SSP until September because I’m currently out of my home country, so I’m hoping to tinker with JUCE tutorials and C++ tutorials until then, and compile links.

Dreams of possibilities:
Teletype i2c interfacing, basically copy the code from the ER-301 and modify it for SSP. I’d have to create Teletype OPs and SSP code to work together, but I think this should be relatively straightforward seeing as there’s a lot of code out there already doing this job as well as an active teletype development forum on lines. Here’s an incomplete compilation of teletype i2c links for this task to get someone situated. Would also open up the SSP to the 16n faderbank as a controller if we get i2c working.

ORCA module - I saw technobear got ORCA running on the SSP, was that a separate application other than SYNTHOR running or was that inside a VST module in the SSP? I’d love to make some sort of 64 x 64 pixel ORCA VST to use inside the patching environment. Just a dream right now, I’ve just been mesmerized by youtube videos of ORCA, I need to download it and play around with it first.

Convolution Module
Mutable instruments ports
Quadraphonic Mixer Module

Edit: I was investigating the Befaco Lich and then learned about Rebel Technology and then learned their OWL patches are all available online as well. Lich supports C++ so it might be easy to learn from some of the code here and compile it for linux / armhf somehow. I’ll have to investigate and write up what is needed to “compile for linux / armhf” if someone gives you a c++ file…
Latest Patches topics - Rebel Technology


you can use whatever you want :slight_smile:
I used to not use an IDE at all, rather just SublimeText (a programmers editor) and the command line for compilation

But a while back , I switched to using cmake for builds as I do quite a few projects which are cross-platform, and so started using CLion by IntelliJ.

( answering from a macos perspective…but the answer is the same IF you are very familar with dev on windows)

it depends on your experience…
if you know how to do things like cross-compilation or cross-platform development then Id say use your native OS… as you’ll be more productive with those tools, and it’ll be more effecient.

IF however, you are not… then Id use linux and follow the setup Bert outlined.
simply because you can get going writing code, rather than messing about for a long time setting up a dev environment.
then as you start writing more code you can slowly improve/optimise your dev environment.

I dont believe so… paging @bert

No :slight_smile:
the VST is already abstracting the SSP hardware.
I run my (SSP) vsts in the (Example) Juce Plugin Host on my mac.

as I stated on other similar topics - I do 95-8% of dev on my mac for SSP plugins,
really I only have to test on the SSP, and adapt things like font sizes and feel of controls when I move it to the SSP… as obviously it looks/feels slightly different on the SSP than when running on my mac.
but functionaly (which is most of the code) its behaves identically on my mac.

that you probably need to breakdown , or look at differently…

so the idea for OWL (and therefore Lich) was to create something that could be written using higher level languages like Faust and Max GEN (not max/msp!) , or Pure Data.

the way this is done is… all the above are able to produce the DSP code as pretty generic C++, they then have a kind of template/code generation around each to create OWL/Lich/Bela code.

the C++ that is produced for OWL is actually not that useful.
instead if you want to do similar, you’d need to write that template.

and owl is NOT the starting point for that :wink:
since many of the above can produce VST code, so that would be a better starting point.

however… that vst code will not use juce, and the ui and cv would not really be integrated well.
so that would need consideration.

overall I’d not suggest this as an early project…its frankly all a bit messy.

also the reason Ive avoided it, is Im not convinced the results are worthwhile.
it would be just as easy to take the DSP and then hand-craft the vst around it, and I think would be a better result.

(bare in mind, the reason Befaco/Rebel Tech wanted to do this was to attract non-programmers, which i dont think really worked :wink: )

as for starting, I always recommend the same thing… just dive in.
Ive always found the only way to learn is to start writing code, and working thru issues I have.
fortunately there is a ton of help on the juce forums, so just go for it.

you have the qvca code in the ssp sdk, so what I did to start was just take that apart and start modifying to my own needs…
just start with something simple as a vst, which’ll allowed you to focus on the rest (like dev envs, juce versions etc)

yes, I looked at the code, and decided it was a bit of a pain to re-write the UI code so that it could be used within a VST context… also frankly to be useful, it would also need new operators to handle things like CV … I think i detailed this all at the time.

what I will be doing at some point is creating a ‘launcher’ for the SSP that would allow us to quit synthor, and then start a different app… (and then when that exits, restarts synthor)
Ive done this on other platforms (e.g. Norns) , it works pretty well.
but just not got around to it.

perhaps one day, i’ll look at doing more with Orca, but so many irons in the fire at the moment :wink:

Perfect, exactly the feedback I needed, thank you. :slight_smile: I’m familiar with programming but I’m not familiar with c++ specifically or setting up environments. I’ve done like, small projects in many different languages, but the environment was always different, either it was low level firmware or high level web dev or Matlab which isn’t really “programming” when talking about “cross-compiling VSTs for linux”, it’s a completely different skillset. VHDL skills are almost useless for Django web dev haha. Last time I used a virtual machine running Linux I had a really hard time trying to get data from an antenna on a USB port to talk to software running in the Linux virtual machine.

Looked up CLion, looks really slick. Sounds like my worries will be cleared up once I start going through some JUCE tutorials. I’ve got a friend who’s a wiz with Visual Studio and knows how to do the cross-compiling things so I’ll bug him with questions, or I’ll just use Vim in Linux and command line for compiling and stick to the Bert outline instead of messing about in VS.

Ahhhh thanks for the clarification on the OWL Lich code! Sounds like it’d be a “make a template / code generation” project to translate pure data to SSP code. Definitely doesn’t sounds like a path I want to investigate right now.

Diving in! Going to hello world it up once I follow the Bert outline this weekend and then start hacking away at some Juce tutorials to get my bearings in there. I’ve found myself in situations too many times coding functions that have already been made because I didn’t familiarize myself with the framework I was working in! haha

Oh! A launcher app sounds great. Aside from Orca, I wouldn’t even know what other app to launch yet. :slight_smile:

Thanks for the replies! Looking forward to yelling at my computer this weekend