So, yeah, many people here know my rants well enough to anticipate exactly what I’m going to say. And they are correct.
So, the TLDR is that if two VCOs have the same features and sound the same, but one uses 4X or even 10X the CPU, that is “bad”. Aliasing – it is very easy to make a VCO that aliases a lot, and not so easy to make one that doesn’t. As someone here once put it “some people can’t hear it or don’t mind it, others hate it, but no one has ever intentionally added it to a VCO”. In my opinion a VCO that generates lots of aliasing is bad. Lastly, DC offset. I didn’t even think about this much until recently, when someone pointed out that DC on the output is not only a bad idea, it can actually make bad sounds. I can’t say that every VCO with DC on the output is “bad” - many of mine had this problem until recently, and many or the other ones still do. But six months from now I will say that all VCOs that put out DC are bad.
When I first started developing for VCV 0.6 it seemed like the number one complaint from people was pops and clicks and other symptoms of CPU overload. When I looked at how some of these modules were written it was clear that they could be a lot faster. So I released “Functional VCO-1” which was a copy of VCV’s Funadamental VCO-1 (old version). It was from 2X to 6X more efficient. Note that the current Fundamental VCO-1 is totally re-written and is better than my old copy, which should be retired. Technical details on that are here: https://github.com/squinkylabs/SquinkyVCV/blob/main/docs/vco-optimization.md
I also made a copy of the AS mixer (which was pretty popular at the time), and even after adding a bunch of features it was 8X more efficient. AFAIK AS has never fixed this, but it’s moot now as the Mind Meld mixers are better than mine or AS for many applications.
At least a year and half ago I published a paper on how to avoid these problems. The doc could use some updating and additions, but it’s still pretty good and popular: https://github.com/squinkylabs/SquinkyVCV/blob/main/docs/efficient-plugins.md
We also figured that some changes inside VCV could relieve the pops and clicks a bit, so we released “Thread Booster”, which changes the way VCV schedules work. VCV 1.0 has this built it (real time thread priority). At the time this plugin was very popular, but we discontinued when 1.0 came out, as it’s now totally unnecessary. Documentation that talks about how it worked is here: https://github.com/squinkylabs/SquinkyVCV/blob/main/docs/thread-booster.md
Standard caveat: there are plenty of modules out there that use a lot of CPU, because they are doing something that just requires it. That is totally legit and reasonable.
Aliasing is a weird one. Out in the world of commercial music software you will almost never see a product that produces a lot of aliasing distortion. It’s something that people have known about for decades and it sounds bad (to most people). But here in VCV there are plenty of VCOs that alias a lot, plenty of waveshapers/distorters that alias a lot, and a few filters that alias.
Aliasing usually sounds like an unpleasant haze over high frequency tones, a “cold” digital sound. Sometimes it manifests as pitches that aren’t supposed to be there, especially when the VCO pitch is rising and you can hear the alias falling (pitch going in the other direction). It can be quite suble to very obvious, depending on the situation.
There are several well known techniques for keeping aliasing under control: oversampling, and MinBLEP (minimum phase band limited step). While these techniques are well known, they still take a lot of code to implement and require a reasonable amount of DSP knowledge. MinBLEP is especially advanced. Luckily VCV has a MinBLEP built into the SDK, and anyone is free to use it. We’ve talked a lot about in the context of our “Shaper” wave-shaper – here’s a discussion of aliasing in that module and how oversampling fixes it: https://github.com/squinkylabs/SquinkyVCV/blob/main/docs/aliasing.md
Growing weary of seeing so many “bad” VCOs, we made an entire open source project that is a series of simple VCOs, starting with one that uses a lot of CPU and aliases a lot, all the way up to one that is very efficient with very little aliasing. There is a lot about aliasing in the documentation – it’s all here: https://github.com/squinkylabs/Demo. This side project eventually led to our “Basic VCO”, which has been pretty popular. The documentation there also talks in more detail about how to measure this stuff and what it sounds like.
Interestingly, high frequency aliasing is a classic part of the Roland JX-8000, so when we made our “Super Saw” emulation we implemented exactly that aliasing, but also provided options to remove it. Manual for that is here: https://github.com/squinkylabs/SquinkyVCV/blob/main/docs/saws.md
Whew! Ok, that just leaves DC. As I say, we didn’t used to pay much attention to it, although we did fix a bad case when a user complained about the original version of our Chebyshev VCO, so we fixed that. Also, Shaper was designed from the start to give a choice of DC or none (when wave-shapers are used on control signals you want to keep the DC). That is talked about in the manual for Shaper: https://github.com/squinkylabs/SquinkyVCV/blob/main/docs/shaper.md
Recently a user pointed out that you can easily hear DC offset on a VCO output if you run the VCO into a VCA that has a very fast envelope. It will pop and thump every time you play a note. If you trigger the notes really quickly the noise turns into a kind of low frequency rumble or hash that is truly disturbing. Once we realize that we went back and fixed some of our VCOs: the saw and pulse outputs of EV3 had DC, same with Substitute (that wasn’t released yet), and our Demo VCO project.
The DC on the pulse waves is particularly common and audible. Most VCOs do this. When they output a pulse they will output 5 volts for the high part, and -5 for the low part. If high and low duration are the same you get a square with no DC. At either extreme of pulse width you get mostly DC and a very little bit of pulse wave. Which will be obvious to math/DSP people, and can be easily measured by the rest of us.
So, DC on a VCO output is “bad” because it will sound bad with very fast envelopes, and it’s bad in general because it may effect something down-stream, like fooling a compressor, riving something into distortion too early and asymmetrically – numerous bad things can happen.
The “silver lining” is that it’s very easy to fix this. Unlike aliasing and excess CPU usage which take a lot of work to fix.
So, anyway, that’s the long version. Bottom line is that unless you have a very powerful computer and only make small patches you would probably pick the module with lower CPU usage if they were otherwise indistinguishable. You may actually like aliasing and want to use it intentionally, but it’s unlikely you want every module you use to do it, and to have no control over it. So, in our opinion, modules that do make a lot of aliasing should point that out in their manuals. And you probably just don’t want any DC on your VCO outputs. If you want that rumbling hash sometime it’s easy to mix some DC in – or just send the envelope to an audio input on your mixer (which will do the same thing).
I don’t think it’s a very pleasant sound. I used a square wave LFO to gate a VCA and ran a narrow pulse into it. It’s super easy to find out if a VCO outputs DC - just run into bogaudio analyzer and look for a big hump all the way to the left - that’s the DC. Here’s an illo: