A couple of months ago we put up a repo on GitHub with a bunch of very simple VCOs. We did this mainly as a way of expressing our dislike of poor quality modules while also doing something positive. Looking back at this code and documentation, the audience is mainly developers, but there is also some (we think) good information for regular VCV users.
The “readme” document is nine pages of information. The most useful for non-developers are the parts on how to test VCV plugins yourself to see how much digital distortion they are making. It also shows in very tangible terms how it is possible/easy to implement something simple in different ways that may use radically different amounts of CPU to do more or less the same thing.
So we hope some regular old non-programmers will find much of the reading interesting and useful.
For developers, especially developers just starting out in VCV, we cover:
How to use MinBLEP (built into VCV) to eliminate aliasing in “classic” waveforms.
Some way to avoid using too much CPU.
How to user VCV’s SIMD library to make polyphonic plugins up to 4X more efficient.
How to write a plugin purely “in code” without using helper.py.
None of these topics is covered in great detail – the plugins are very simple.
Since writing that we have become obsessed with DC offset on VCO outputs, and the “best” plugins in our demo do indeed have this flaw. Hopefully we will update the code to fix this in the near future.
This code repo is completely separate from our regular SquinkyLabs repo – it just contains these simple examples. We hope that makes it a lot easier to browse.
And, just to plug this old chestnut, we wrote a document on how to write efficient plugins 17 months ago. It is here: https://github.com/squinkylabs/SquinkyVCV/blob/main/docs/efficient-plugins.md. While it is badly in need of an update, the information there is still mostly accurate. It’s a nice short document, but in this case aimed entirely at developers.
Yes, it is at this point completely an affectation that I pretend there is more than one person doing business as “Squinky Labs”. Originally there were two, as Lloyd Cole is the founder of Squinky Labs, and we made some firmware for the Eurorack module “Disting”. He’s not interested in “desktop” computer software. So since switching to VCV it’s just been one. Early on I was hoping to draft someone else, but at this point, as I say, the “we” is entirely an affectation (or an old habit).
Well, I think it’s very much like Lindenberg Research, a huge facility deep inside the mountain, surrounded by barbed wire and electric fence, drones, cameras, multiple checkpoints, a private army of armed guards, former black ops and mercenaries, guarding the science team who deal with hazardous materials, portal technology, extrasolar and interdimensional objects and spaceships (aka “weather balloons”) captured by the military, possibly even living subjects and alien/human hybrids, in order to obtain superior DSP technology out of reach from even the shadow governments and lizard people.
You can’t hide the truth, man! This is what they don’t want us to know.
haha - I like that image. Is Lindenberg still in the module business? Some of the filters and VCOs are really well regarded/popular, but I haven’t noticed any new stuff lately.
Great resource for testers and would-be module coders, thanks Bruce!
I read through it but can’t remember - did it end up adressing DC-output or is that a TODO?
It is good to see an alternative to the dc offset reduction method I have been using of a High pass filter set at 5Hz, I shall be trying out your technique.
Are there are good resources for SIMD programming paradigms anyone could recommend please? Like you mention in your documentation I have had varying results, from a decent improvement, to code that runs slower. This is an area I would like to improve my skill set in.
Good question. I’m hardly an expert. But probably the easiest thing to do is use SIMD to speed up polyphonic modules. This is less difficult, and almost always gives a huge speedup. For doing this the source code to the Fundamental modules is an excellent resource. There are other plugins that use SIMD to speed up single channel operations. I believe Surge does this, but that code uses SIMD intrinsics, and is not for us non-experts.
Yes, if you can use my simple technique it has some advantages, primarily it does not affect the waveform at all, other than removing DC, it takes very little code, and it requires very little CPU. There are many cases where you need to use a HPF, usually because it’s impossible to “guess” the offset and subtract it like in VCO3. We use a HPF in “Shaper”, our waveshaper, because it would be very difficult (impossible?) to estimate the DC generated by those functions.
The most important thing to me with all these issues (aliasing, CPU efficiency, DC artifacts) is that people be aware of them. Clever developers can find many solutions to these problems, but they have to know that the problems exist and that they matter to end-users.