TheTechnobear's VSTs development

Blades is not viable
Like beads, it’s not open sources yet.
it’s an analog filter , so would need circuit modeling. Not something I currently have experience of … and I guess a tough first try !

1 Like

yay we are very nearly there !!!

today, I have make available a pre-release of ALL my plugins via Early Access on

(thank you to all those supporting me!)

I just want to do some final testing on this pre-release, and see if there are any comments on it. then I will release.
I’d appreciate those with Early Access, installing and letting me know if they see any issues, or have any suggestions.

hint: there is a new algo in SWAT, also you’ll see a nice (I think) small UI change in PMIX


oops, ko-fi preview page caught me out… the pre-release is now available on early access.

Thanks for all of your work on these!
Approximately how many cups of coffee would a grids port take? :grimacing:


I’ll have a look at this :slight_smile:

at the moment, I want to get this release out
(its basically done now… just not had any time this week)

I then want to do some more work on the oscilloscope/data plugin - ive had hanging around for some time now.
after thats done, I was thinking of doing a multi tap delay,
but perhaps could squeeze grids in - its actually pretty straightforward, the actually dev is probably not more than a few hours, then its testing/release.

1 Like

Looking forward to you pushing your code to master, so I can see the restructured version and learn from it :slight_smile: especially if you’ve introduced CMake…

Regarding the oscilloscope module, feel free to use this as a starting point, or maybe we can consolidate them in some way. It’s been a gently way to get started and a good forcing function - now I have to figure out how to take user input from the encoders!

1 Like

I already started on it a while ago… but got a bit sidetracked… (*)
it takes a bit of a different approach to the way QVCA/SCP works,
primarily, since I need a variable timebase, so I cannot use the audio buffer from the processor directly. rather I sample in the processor, then send a variable number of samples to the editor.
this approach means I can have a timebase that can range from individual sample, to seconds or even minutes… and only keep the the data at the resolution I need to display.

(*) as mentioned in this thread, I decided, I need to refactor everything… so didn’t want to finish off this vst, only then to have to re-factor it… also I could see it needed a few things which I was going to add to my infrastructure.

Aha, so that’s the solution to the timebase problem :slight_smile: I was worried that wasn’t possible, but that just shows I have a lot to learn in the VST and even audio processing world. That will be awesome, I think the module is of limited use without that. Look forward to seeing how it works!

well mine is one solution, as is often the case in development, there are many solutions, each with pros and cons.
my approach is pretty efficient, but has a small con that if you change the timebase the ‘rolling data’ needs to be rebuilt. this is actually pretty common, you’ll often see oscilliscopes ‘restart’ when the timebase is altered, though you only reallly notice this when you start using slow timebases ( e.g. seconds)

anyway… I’ll see how it ‘feels’ in practice, I can quite easily adjust if I have useability concerns.

Holy cow! Are you about to make data and rainmaker redundant from my rack!?
I bought a data a few years ago because I wanted something to calibrate certain diy modules I was building, turns out I really like that module (clocking is underrated fun) , but it can obviously only be set in one mode at a time…having multiple instances of it on the SSP would obviously be pretty (very) special.
Some hypothetical questions. From what I remember data is on par to a decent lab oscilloscope/frequency generator and mostly software based so do you think you could match that in accuracy (I’m guessing so)?
Would it have all the modes the data has?
At this rate I’m going to end up with a rack full of SSP’s

1 Like

I really like data when I had it…
but i dont think its that accurate, but it doesn’t really need to be for audio use.
(I can’t say Ive seen anything claiming it was super accurate?)

so the SSP variation will be accurate for internal voltages,
however, as soon as you introduce external voltages, its accuracy will be determined by the accuracy of the ADC - this is pretty good for the SSP , however it is not calibrated.

perhaps at some point, we can look at a calibration module, but that would require the user to have an accurate multimeter … as calibration always requires an accurate reference.
we’ll see, certainly not something Ive planned on yet. mainly I see this as a visualisation tool.

as for functionality, Ive not decided what to include yet.


Yep you’re right can’t really see anything about accuracy and like you say it doesn’t need to be that accurate for audio so I probably just imagined that for some reason, but still interested in what you come up with. :+1:t3:

Release Day

1.3.1 is out !

download from here :

as with previous release, ALL plugins are contained in this one download.
It’s hard to say what all the changes are , since frankly its a re-write of all my plugins.

the main changes are :

new UI,
supporting default, fine/coarse on all parameters
nicer colour coded parameter display

important architectural changes
using latest version of JUCE
using latest build system (cmake)
all plugins built off a common architecture
plugins now support full automation (*)

note: compatible with previous version, old parameter values saved in presets will NOT restore correctly.

(*) not accessible on synthor at present

there are some functionality changes to individual plugins as well, e.g. I add a sample based delay to SWAT, there are also some bug fixes (e.g. SWAT was displaying some notes incorrectly)

ko-fi supporters
thanks again for your support, it means a lot to me!
there are some minor changes since the early access, so you will want to download this release and install.

possibly the most exciting part about this release is that now all plugins share a common code base, I can now add new features easily to them all by updating this framework - so this effort will yield more benefits in the future.

note: Ive updated change history on each module post here on the forum, but given all modules changed Ive not added a release post to each .

apologies, that it took a bit longer to release than anticipated…
I have to admit, this is because I bought a new drone recently, and have been pretty obsessed flying that in my spare time.

anyway, if you have an issue with any particular plugin, please comment on that particular plugins post.
(rather than clogging up this post, which Id rather keep for more general development news)

Im happy to get this release out, as it means I can focus on something new, so looking forward to that.


Congrats and thanks for all the hard work! Looking forward to installing the final versions of these tonight and will look for any issues. Looking forward to the productivity that will ensue going forward as a result of the rewrite, too!

Also, I will gladly buy you another coffee for pushing to Github :slight_smile: Cheers!

yeah, I need to sort a few things out first…

a) dev enviroment
I tried to install the dev environment on a 2nd mac that I have, and its not working… seems to be something to do with versions of tools homebrew installed. I spent about an hour hunting for issues, but couldn’t resolve.

b) sysroot
I tried to zip this up and host it, but that is not going to work, its too big…
I could potentially script building this… this is kind of where I started from.- but I do not have time (or energy) for this at the moment.

so whilst I could publish it, its unlikely to work for anyone, and I dont have the bandwidth to work on these issues at the moment… and Id really like to do some fresh development - but bored of this infrastructural stuff at the moment - so, I’ll chip away at them in the background.

Thanks so much for this release @thetechnobear! I had a quick play with it today. The usability is an enormous leap forward. Despite there being more information on display, it feels spacious. Love the small font as used in Clouds’ freeze button! This shows how much more can be done with the SSP’s screen real estate.

1 Like

I don’t fully understand how the dev environment is coupled to the code, but at least for the sysroot part (this is for cross-compilation, right?) would this be a good use case for Docker (or something else like Vagrant)? If you can specify the environment in terms of running commands on top of a base image (eg. to install dependencies), then you can turn it into a Dockerfile and make it reproducible.

Here’s an example Dockerfile using the Dockcross project, which provides base images with the toolchain already installed (configured for CMake), and basic instructions in the README here.

Again, I’m sure I don’t get all the nuances, so apologies if this is not relevant to your situation.

I’m familiar with docker - it doesn’t buy me anything in this case, and is just an unnecessary complication.

I just want to say thank you for the new update, the new UI is very nice!!

1 Like

I’ve been busy on other (non-ssp :open_mouth: ) projects.

but happy to be back on the SSP, its also nice to be doing something NEW for the SSP.

see my IG for a a little video

also my ko-fi blog for more details.

less blurry images from my desktop … instagram does not do SSP display justice.