New synth articles and a facelift to the Demo site

[Squinky]

Many people here have probably seen this site before, but I have a second repo that used to contain a walk-through for how to make a VCO that uses very little CPU and has no audible aliasing.

I also have a paper on tips for writing plugins that don’t waste a lot of CPU that many people are familiar with.

I moved all the papers, and some new ones over there, so they are in once place. They are now at: GitHub - squinkylabs/Demo: A collection of code and articles of interest to VCV users and developers.

While I was at it, I finished a short paper on the evils of DC on the output of audio modules (and how to get rid of it), and a paper on the effect of delays in the VCV-HOST module, and how to avoid getting into problems with that.

As has always been the case, the section on the demo VCOs has lots of general information on how to measure aliasing using a spectrum analyzer.

Hopefully these articles will be interesting to some people. I have tried to keep any obvious “Squinky Labs propaganda” out of there.

[LarsBjerregaard]

It’s a great community resource Bruce, thanks!

[hemmer (A Forest Full of Sines)]

Great resource, inspired me to fix up EvenVCO pulse out. It was a one line change…

diff --git a/src/EvenVCO.cpp b/src/EvenVCO.cpp
index fa2c4b3..34d97f6 100644
--- a/src/EvenVCO.cpp
+++ b/src/EvenVCO.cpp
@@ -186,6 +186,7 @@ struct EvenVCO : Module {
 
 			square[c / 4] = simd::ifelse((phase[c / 4] < pw[c / 4]),  -1.f, +1.f);
 			square[c / 4] += squareMinBlepOut[c / 4];
+			square[c / 4] += 2.f * (pw[c / 4] - 0.5); 	// DC offset correction
 			square[c / 4] *= 5.f;
 
 			// Set outputs

Now

Before

[Squinky]

Oh, nice! I’m hoping a lot of people will make this simple improvement to their pulse waves. It’s much smaller, but of course even always had the DC on the saw, too. In fact I think someone logged that as a bug years ago. Admittedly my hack will add DC if VCV SDK ever fixes that bug in the minBlep.

Seeing c / 4 makes me think that the new EvenVCO will by poly, using SIMD, which is great. iirc when I made EV3 from EvenVCO I was able to hugely reduce the CPU usage (although EvenVCO was always pretty good with the CPU anyway). One thing I remember was not running minBLEP when it wasn’t needed (in you case output not patched). And maybe the original Even used std::sin instead of a faster approximation?

Anyway - thanks for taking out the DC on the pulse!

[LarsBjerregaard]

@hemmer

inspired me to fix up EvenVCO pulse out

+1 outstanding attitude!

[hemmer (A Forest Full of Sines)]

EvenVCO, as is currently in the library, is now already poly, but I have a task on my backlog to overhaul to improve the performance exactly as you say (including implementing sync). I don’t know if that’ll make into the next release but it’s planned.

[Squinky]

Please don’t use my sync implementation from EV-3. I’m not very proud of that (but at least it works!). I think the one in Fundamental VCO-1 would be a much better model.

[diimdeep]

Cool. I’m interested in techniques(proper!) about FX type modules where algorithm require internally more than one sample and up to 1024 samples to work.

RNnoise for example requires 480 samples frame size.

[Squinky]

In vcv it would need to save up enough samples to start. So it would introduce that much delay. Since vcv has no delay comp (and shouldn’t) that means your effect will introduce that much delay. Unless I’m missing something, that does not sound very “modular friendly” to me.

[diimdeep]

There is friendly ways to compensate delay with existing modules.

AFAIK there is eurorack hardware with that much (10 ms) delay.