what is a "bad VCO"?

from Other topic

all this whole thing is new to me, and I must admit I m ignorant, but in other hand I can (based on the perception ) appreciate a distorted sound , a decimated sound a filtered sound and so on, also I can appreciate the beauty of all of the sounds , and sometimes I think I can Express myself or understand what some artist want to say with them music , but I’ve never caught myself saying "Oh my god, that is a really good (or bad) VCO " when I listen my favorite Artist. I just simply like or not.

to me every VCO have its own character, the only difference that I can see (but not necessarily it mean is bad ) is how much CPU it need

I think it is a topic where only if you are in the DSP thing you can appreciate it , so , what you considerate to know if a VCO is good or bad?, does this really matter?, what effect a bad VCO produce music or in the listener?

1 Like

I don’t wanna answer on SquinkyLabs’ behalf but something tells me the term ‘aliasing’ will appear several times in his answer :smiley:


Seeing as ‘aliasing’ is already taken, I’m placing my bet on ‘DC Offset’ making an appearance.


To me a “bad” VCO, is more of a demanding VCO on the CPU. When it shouldn’t be necessary.


I don’t like the ones that go “bzzzzzzzzt” i prefer when they do “bwooooooooooo” :crazy_face:

Jokes aside, I don’t know much about DSP, but i think most people are going to say the criteria are Aliasing, DC offset and CPU usage Optimization.


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).


As much as I can understand using aliasing in creative ways, I can’t think of any way this could be desired. Do you have any examples?

1 Like

I wanted to make a video, but don’t have time :wink: 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: https://github.com/squinkylabs/Demo/blob/91f8afa60126f08888eea315279cf76110bd26c1/docs/analyzer.md

1 Like

I’d roughly classify a good VCO to have the following objective characteristics.

  • Static (behavior when no parameters are changing)
    • Not playing harmonics that aren’t supposed to be there
      • Anti-aliasing: If you don’t use an anti-aliased algorithm, supersonic harmonics will be reflected across the Nyquist frequency, into sonic frequencies.
    • Playing harmonics that are supposed to be there
      • Making sure all harmoincs up to the Nyquist frequency are played at proper amplitude.
      • If emulating an analog waveform, often harmonic amplitudes are different from ideal definitions of the waveforms. For example, most analog saw waves aren’t just A_k = 1/k. Sometimes amplitudes are dependent on the oscillator’s frequency. Test your favorite oscillator in a frequency analyzer to learn more.
  • Dynamic
    • Control-rate modulation
      • No clicks when parameters change
    • Audio-rate modulation
      • If you want to get fancy, interpolate parameter values between samples. For example if using oversampling, linearly interpolate x_\alpha = \alpha x_0 + (1-\alpha) x_1, or use higher quality methods that depend on more previous input values.
  • Misc
    • Stable: Doesn’t generate non-finite numbers at any time, regardless of parameter state and input signals.
    • Uses nearly the minimum possible CPU for the given algorithm, by using mathematical tricks, avoiding unnecessary re-computation, etc.

This is a very good list.

1 Like

A lot of great sounds were born out of the defects and limitations of cheap hardware that made harsh trade-offs and had weird bugs, especially game console chips. When reproducing real hardware, I think accuracy trumps everything: without a bug-for-bug compatibility mode, you’ll never get the proper timbre.

1 Like

For sure. That’s one thing that’s really good about Andrew’s list. Basically, for everything the VCO does, was it done on purpose, or is it a bug? So any squeek/click/alias that’s in there on purpose is 100% legit. but, I think I’m not along in thinking that if a module isn’t obviously a model of some old thing, and the manual doesn’t explain why it was done, then the odds are it’s not intentional.

1 Like