TheTechnobear's VSTs development

all quiet there, but in the background I’m beavering away at SSP related things…

the main things done, is to ‘modernise’ my build tools/libs

  • major refactoring of code to move to the latest juce
  • I/ve changed my entire toolchain to cmake/clang

at this point, I was experimenting with my new framework for the plugins…

but something else happened…

I got a new Mac Mini (using the new Apple Silicon!)
this has meant updating my entire development environment for SSP plugins - a task that took a while, since alot of tools are in thier infancy for Apple Silicon.

Fortunately, my move to the latest tools meant that I could get latest updates required for Apple Silicon.

now the good news, the result of that effort…

  • development build (to run on mac)
    I can build ALL (8) of my plugins in less that ONE (!) minute,
    it used to take about this for ONE plugin

  • build of SSP plugins
    I used to have to compile for the SSP under a VM (running debian) using emulation (qemu)
    this was really painfully slow, it could take around 30+(actually probably more !) minutes to compile everything - fortunately, I didnt always have to build ALL, but still compiles were usually 4-6 minutes.
    NOW … I cross-compile natively on the mac mini, no messing with VMs or emulations.
    so I can build everything in … yup ONE minute… thats a full fresh compile, normal ‘dev cycles’ changes, compile in a few seconds.
    its awesome !!!

(there are some bit still missing, e.g. CLion Im running under Rosetta, but thats not really an issue)

so this did take a while, but the benefits are huge.

now I need to get back to the framework refactoring, Im starting with CLDS as the ‘experiment’… once I have the framework as I want it, then I’ll update all the other VSTs to use the new approach… then look at some new VST ideas :slight_smile:


Great news! You’re a heck of a developer, very grateful for your work!

I wonder if you think it’s possible to take CSound applications and turn them into VST for the SSP. Because a lot of that stuff is open source, and the code seems to be freely available.

Maybe you’ve come across this awesome sound design environment called Cecilia?
It’s basically a buffered realtime audio processor, capable of quite mindbending operations. If I’m not mistaken, it runs on CSound.

The other thing I wanted to ask is: Will you have a look at the newer version of Clouds by Mutable Instruments called “Beads”?

And glad to hear that the new Macs are running great, I will get one of these aswell.

1 Like

thanks :blush:


most likely, I ordered one yesterday - very excited :slight_smile:
however, Emilie does not release the source code until about six months after the hardware release.
so I suspect it will be late 2021 until this happens.


yeah I know CSound and familiar with Cecilia.
unfortunately, I don’t think Cecilia is a helpful route to get CSound on the SSP, as its a standalone environment - so would not integrate with Synthor. also realistically the UI would probably be too ‘big’ to fit on the display.
also frankly, Ive had bad experiences getting wxPython( which is uses) to work on some platforms.

I also looked at Cabbage which can create VSTs, but the SSP use of a vsts is a little different from normal - so I dont think its that useful
example: we have lots of audio channels in/out which we use for cv… vst generally only have a stereo pair, and are only ever audio

so its not a very simple task, basically Id need to embed csound (that I kind of know how to do) , and then have a way to allow the user to create a UI (for parameters), my current thoughts are perhaps lua.

i do think this would give us a very powerful way to create vsts, that potentially non-programmers could use ( * ) - so its still on my ‘ideas lists’

( * ) lua and csound are still programming languages, so there is still a learning curve - however, they are much simpler for non-programmers than something like C++

on a more general note, various stuff has been going on in the last couple of months, which means I didnt make any real progress on my vsts - however, I back on the case now :slight_smile:

1 Like

Very interesting insights, thanks!

Well, what I love about Cecilia is certain spectral modules and pitch shifters. I just thought it would be crazy if those tools were available on the SSP.

OK, I didn’t know that about Emilie’s source code, but that makes totally sense.
I’m also getting mine soon, I heard only the best things about Beads.

So far loving your port of Clouds, a port of Beads end of 2021 would be amazing :exploding_head:

1 Like

@thetechnobear Hi,

I’m an expectant SSP owner and as a programmer also, I’m looking forward to trying my hand at seeing if I can contribute to the VSTs available on the platform.

To that end, do you have any code and/or tips to get people started? For instance, is this new framework of yours open source?

I personally have a web development background and am not very experienced with C, or C++. Is that a big hurdle? Is it the only option for VSTs?

I love the idea of making more MI modules, and in the absence of Beads, my first target would be Marbles.


cool @littlebear

so Bert has published a guide on how to get started with writing vsts for the SSP.

the percussa SDK has an example VST with source code included in it.

generally its using the JUCE framework (
which is free to use for open source projects. (i.e. GPL)

the great thing about JUCE is its an ‘industry standard’ , so its really well documented, and has an active forum to get help from fellow developers.

when I release modules I make the source code available - so my current dev work is only available once its released - but all released modules are already there.
(I should say, as much as I would like too, I do not have time to start doing ‘developer support’ for these)

I’d highly recommend you look at @bert’s example first, as its simpler, so its easier to understand whats going on. once you understand that, you’ll be in a better position to look at something a bit more complex.

hmm, honestly hard to say… as its not my background ( I came from a C/C++ background).
C++ can be a bit daunting, and then you have to learn the JUCE library, and how to port it to the SSP - but as i said JUCE has excellent documentation, and tutorials - so if you put in the time, Im sure its possible.

generally VST is a binary protocol, so they can theoretically be produced in any number of languages - the ‘issue’ is many alternatives might require runtimes that are not present on the SSP, which then means installing them… which then means other users would have extra steps to get the VST working - so this is something Id avoid.

(this is why Im considering things like csound, lua, libpd as these can be embedded into c++ built binaries)

yeah, MI source code is a great source of modules :slight_smile:

however, bare in mind they are also written in C++ - this means you need to be able to read C++ reasonably well, to determine which bits of the code you need in your vst (e.g. remove the hardware specific code) , and how you will interface with it e.g. how do you need to prepare your data to make it work with other bits of MI code.

again, Im not trying to put you off… just pointing out, its not just a matter of including the code and it magically just working … theres a reasonable amout of understanding of the code required to do it.

on the flip side, once you actually know what is needed to be done - you dont have to write much DSP code (as you’re using Emilie’s work) , mainly its UI code and interfacing to the MI code.

anyway, I highly recommend you give it a go…
It might take a bit of time… but its a very rewarding experience to see your own code running on the SSP :slight_smile:

That’s great, thanks - will check all that out! Sounds like quite a time investment that I don’t have, but we’ll see :slight_smile: It would be its own reward.

yeah, unfortunatley, as Im sure you found in web development… initially there is quite a lot to learn.

Ive been asked about this quite a bit (on various music forums), and I try to liken it to music…
sure, anyone can pickup a guitar and strum some notes… but if you want to release (an album) or play on stage, your probably going to need to invest some time practicing :slight_smile:

unfortunately, coding (esp. in C++) is not that forgiving, you can’t just wing it - if you do, it’ll just crash and burn… ok, nothing actually burns… but its not pretty, and can be a pretty frustrating experience (like most things with computers)

BUT … just like music, programming is a real creative endeavour - you start with a blank page and you make something of it.
I think coding for the SSP is really fun, since not only can you make it look nice, and sound great, but it also interfaces to the rest of your modular … so you are extending an ecosystem.
the whole is greater than the sum of its parts.

so go for it…
my advice is start SMALL and simple, the most important thing is build something that works, then take the next (slighly bigger) step - and you will get there.
(most fail, because they are too ambitious at first, and just get frustrated and disheartened)

something tiny like, build a sine oscillator… it doesnt matter if its useful or not, the point is YOU made it… then add inputs, then a UI , then a saw wave… each step adds to your skills.

1 Like

That is good advice, thank you.

1 Like

Feb Update on Ko-Fi

Thanks again to my ko-fi supporters - I really appreciate your support.

The update is public, so won’t repeat contents here - except one point, to encourage you to read it…

the re-work on plugins is going well ( *1 ) , and Im now turning to the UI aspect.

I hope to have a new generic UI ‘prototype’ coded today ( *2 ), which will show an idea of where I want to go,
and Id like to get some feedback

first some information/context

the UIs of my plugins fall into 2 broad categories

  • generic
  • dedicated.

Generic are like clds, plts - its a common (or will be after this re-factor) UI, where they display the parameters as ‘text’ values and you can move though ‘pages’ or sets of these parameters.
Dedicated is like pmix, where the UI is much more tailored to the plugins needs

generic is not less here, alot of plugins don’t really “need” an elaborate ui - and avoiding a dedicated ui will make development quicker - so more time to work on other plugins or the dsp code.
however, of course, something like pmix without seeing vumeters wouldn’t be anywhere near as useful.
note: I should say, there is no hard divide between these two categories e.g. a generic ui, can have specific UI elements added to it, similarly a dedicated ui on plugin still sits on same framework…

so getting the ‘generic’ ui looking nice will affect all of my plugins, existing and future ones.
hence why the prototype is important, to show some ideas of where Im considering going and what functionality it needs to have (given it needs to work for many plugin covering different functionality).

at this stage, Im still open on what it will look like, so your input is very welcome.
obviously we will need to discuss various requirements it has :wink:

it will likely start fairly simple, but because all my plugins are built on the same framework - it can evolve over time, without too much work to individual plugins.

again, thanks for your support - im pretty excited about getting this new stuff out,
and then being able to work on some new plugins :slight_smile:

*1 refactor recap : why?
the reason this re-work is important is simply, Ive now released quite a few plugins - so ‘maintenence’ is becoming an issue - adding a new ‘feature’ (e.g. fine tuning) is quite a lot of work if I have to go an re-do it on every plugin.
so the idea is…
once all plugins have been re-worked to the new framework, adding a new feature is pretty straightforward - it will also make it quicker to create new plugins, as alot of the code is already in place… so I can spend more time on the DSP code, rather than the UI etc.

*2 prototype
its only the UI thats a ‘prototype’ - it’s actually a fully working plugin using this UI.
so I guess is more of a ‘rough cut’ of a new idea, so most likely will be evolved from.
but we will see…

Ive posted my current prototype ui on ko-fi ( again public) - the post details my current thinking, and why it is as it is… what I like, what i dont :slight_smile:

thoughts? other ideas?

Well I like and agree on seeing as many parameters as possible. No other ideas. Marvellous work and good to see the SSP is back up and running.

1 Like

great, some form of levels (you mentioned a VU meter) is maybe more of interest / use than a drawing of a cloud

Great ideas! My detailed comments are on the ko-fi forum. The picture below illustrates some of my suggestions…


yeah, im kind of leaning a little away from displaying values as text…

heres two new ideas I tried this morning …

some thoughts…
the bars will need an end indicator (probably a filled circle if I use rounded bars), a line if I use rectangles.
two forms , unipolar (from 0) and bipolar ( centre =0)

Im not sure about the value text… I know its useful at times…
however, i like the fact in modular we use our ears … so often knobs do not show values.
perhaps we might need detents… on the bar to give us positional info?

this does form a bit of an issue with something like mode… perhaps I could have radio buttons?

one option if I get rid of the value , might be to have a small area such that when you turn an encoder it shows the values whilst turning (only issue is when you turn multiple encoders, but thats likely ok)

yes, the cloud will go… and likely be vumeters, but please bare in mind these are working prototypes so I need to code the vumeter (well -refactor from pmix) , not just paint them on :wink:

Sounds like a great refactoring. Is one of the goals to make a generic plugin “framework” that others (like myself) could use to create other plugins? If not, could it be? :slight_smile:

In other news, got my SSP yesterday! Don’t have the case yet, but when I do… will be looking into plugin development in the meantime!

Edit: Thanks for mentioning Ko-fi, didn’t know about that.

1 Like

@titaanzink thanks for the detailed points on ko-fi, Ive replied there…
btw: i dont disagree with them (even if I sound like i do) , rather its kind of a discussion… back n’ forth.

colours, they were just obvious ones to choose, very happy to switch them for a different palette. suggesions welcome
(bare in mind they may look different on the ssp display, so we will need to try)

it’ll be open source, so you could choose to use it , or adapt as is…
obviously since, I’ll be moving all my plugins to it, will will be ‘generic’

that said… I dont plan to give dev support on it, nor guarantee things will be stable i.e. I could decide to change things (however, you can get around this by simply forking it… so thats not really an issue)

cool…exciting times :slight_smile:

Yeah, I think this is fine… your goals help our goals!

1 Like

My tiny idea for UI is,
Adding a help page, description of parameters etc, because SSP has a large display.
Maybe, combo button to open a help page is better for avoiding to open at unwanted timing during play the SSP.