DC offset on VCO outputs is bad, part #137

Didn’t want to hijack the Surge XT thread any more, don’t really want to make @hemmer mad any more. Afaik he’s nice person who makes good modules, as is @baconpaul.

But it doesn’t change the fact that DC offset on the outputs of a VCO is a pretty bad mistake to make. It’s going to make patches sound bad, and ppl won’t know why.

It’s great the the EvenVCO will get that bug fixed. But is has been in there for 4 years and is still in the library like that.

I’m sure all these modules will get fixed sooner or later. They are already great collections, will be just a little better then this issue is fixed.

The surge modules were all fixed 13 hours ago though! Did you mean this for someone else?

1 Like

But anyway if you did mean it for me (the third person reference to me threw me off) I agree that dc is bad! Like I said surge has an always on hp filter I just forgot about when I exposed these which was the missing solution.

And I also agree that the dsp quality in rack is …. well let’s say it is varied.

You know what would be a lovely module. A module with a v/Oct and gate out and stereo in you could hook up to a vco + envelope pair and it could diagnose common dsp problems. Like dc offset or draw alias reflections in a sweep fft. Then newer devs would have a chance at at least knowing they were off.

The general lack of test and validation infrastructure is surprising. Like rack 2 didn’t come with a check that all your ports were labeled and so on. Maybe invest in that as a way to address these problems?


Me? No thanks!

Right - Well if anyone else has ‘dev validation modules’ I would love to try them out.

When rack 1 added polyphony and I was porting from the 0.6 modules I had, I wrote a polyphonic test generator (which is still in BaconPlugs) and I used it all the time then, and also all the time with this go round. Some other structural tests would be really lovely.

I guess I could just write those though. The API has enough information in it I think!

But our experience over in CLAP land was: if we want something to be true of all plugins and we can’t enforce it in the API, put it in a validator. Your comment made me think of the same thing here. As you saw fixing the DC in surge took me a couple of hours (plus a small pause to let someone test) but, like, why wasn’t that part of my ‘how to make sure your module is good’ pre-checkout using the ‘good modules dev tools’ plugins.


oh, it would for sure be useful. That way to tool would get threatened with perma-ban, instead of me. But I just don’t have the motivation to invest all the work to write a tool like that. Maybe Andrew will.

That is a neat idea - not sure if I have the time to take a crack at it but would love to see it. Maybe start a dev thread with the suggestion and see if anyone rises to the challenge?

1 Like

I think it’s a great idea paul. I think you need two kinds: The live module you mention that can do analysis, and then a static code linter will also be needed, for things like missing port labels and other code deficiencies. I share your surprise about missing such tools in Rack by now but I’ve come to the conclusion that it’s because Andrew is a great starter but he’s not a finisher, notice e.g. the state of the manual, so I’m pretty sure that this will be up to the dev community. In the meantime we thankfully have modules like Bogaudio Analyzer.

Also I’m not mad squinky, just wanted to make sure you knew there was progress on the Befaco side. :blush:


I got the linter started and running last night and it can detect unnamed ports and params already. If I get more done today I’ll start a dev thread. It was pretty easy, it’s in my next branch of the newly revived baconplugs.

The signal one is harder obvs.


Not sure what was the point of this thread - there are more efficient ways to do bug report :wink: - but it’s an interesting direction!

Question to friends devs about DC offset in VCO: Common sense tells us big no no, but when I got to Serge synths, I was surprised how most sound sources where 0 to 5 V, with no effort to make it bipolar, both on vintage and modern circuit. The oscillators are mostly unipolar, and of course, you often use function generator (looping enveloppe) as sound source, and Serge is often regarded as great sounding. Even the eurorack NTO which is well regarded VCO has saw and triangle output unipolar (it does have other bipolar outs though)

Comming to the question: is it tipically a curical point in digital audio? Thanks :slight_smile:

Well filters help tame it in many instruments (including the surge modules where I just added a dc blocker filter on back of the circuit)

In surge vst we had to fight it when we introduced a waveshaper where 0 input mapped to non-zero output since that would lead to audible clicks on some release cases.

Untamed high dc can also damage speakers. There were a bunch of “how to destroy your clubs pa” bugs at the edges of surge 16 which korridor helped us pin down, but those were less dc and more unbounded modulators

In the little oscillator workbench I started working on a bit ago I did a simple sweep and visualize to detect aliasing and dc; that module was one which would be nice in addition to the logical stuff. If I write it maybe I will call it the “HappySquinkyInator”


Here’s the thing i wrote a bit ago to help me develop new oscillators. (That’s an unreleased oscillator based on using networks of all pass filters to generate phase distortion)

You can see at the bottom we sweep frequency up and down and take FFT and you can see that the aliasing is “low” (the echoes) but not “zero”.

Something like that as a rack module would be lovely it seems to me.


Nice! - How about:

“The Squinkinator” or “The Squinky Lab”


“Auntie Alias”


“Aliases Anonymous”

You are a wizzard, sir!

I don’t think I’ll ever understand that. It violates my entire idea of what “audio at audible frequencies” is. It certainly doesn’t work like that in nature.

  • The Rack module sanitizer
  • The badness detector
  • RackBlame
  • The nastines visualizer


Me neither really. I had a probably naive understanding that it is the bipolar nature of audio signals that makes speakers work by moving the cone back and forth.


Theoretically you can produce audible sound in a unipolar fashion, the only requirement is “air oscillating”. However, the mechanical requirements of speakers, eardrums and vocalchords etc. don’t support such a mode, so they are all bipolar, and everything “struck” or vibrating in nature is bipolar. So in a very practical sense sound is bipolar.

Bipolar oscillation is Strain->Relax (swingback), unipolar is Strain->Strain, so very mechanically inefficient.

1 Like

I started it. I wanted to talk more about the common problem of DC on outputs, and did not wish to hijack an existing thread.