Oscillators

[martinvicanek]

Hi gang!

Over the years I have been accumulating knowledge about oscillators, and I would like to share with you some results. You may ask, "Is not everything said and done about oscillators?" or "Why bother, we have the stock oscillators after all!". Well, the stock oscillators are not very CPU efficient, and they have a number of limitations like artifacts at low frequencies. Also, there is no random LFO of any sort. And, hey, isn't it just cool to have your own oscillators?

I have four contributions in the pipe on harmonic oscillators, classical waveform oscillators, noise generators, and LFOs, respectively. Today I will release the first one.

Happy Flowstoning!

[martinvicanek]

Harmonic Oscillators

A harmonic or sine wave oscillator generates a pure tone without any harmonics. It may be used for additive synthesis, where a number sine waves are added to generate timbre – the Hammond organ is a prominent example of this principle. However, harmonic oscillators are also useful in various DSP applications like heterodyning, frequency conversion, etc.

Methods for generating sine waves fall roughly into two categories:
1. Recursive oscillators, where the actual output value is computed from previous states
2. Direct evaluation as a function of a phase accumulator (= non band-limited ramp)

There are many algorithms for recursive oscillators, with different characteristics in terms of accuracy (especially at low frequencies), stability, computational complexity, etc. Clay Turner has a good overview in http://www.claysturner.com/dsp/digital_resonators.pdf. I have chosen two such algorithms for their unique properties: the Reinsch oscillator as the fastest possible (static), (hyper)stable, low-frequency accurate oscillator, and my own quadrature oscillator as the only hyperstable, equi-amplitude quadrature oscillator that I am aware of.

Recursive oscillators perform best at constant frequency. Modulation requires coefficient(s) updating and may often result in amplitude change. It is somewhat difficult to add phase modulation (it can be done for a quadrature oscillator, but it is not very efficient).

Direct evaluation methods often reduce the range of the phase argument by exploiting symmetry, and then proceed by approximating the sine function by polynomials or rational functions. Another option is to use a lookup table, possibly with some interpolation. The stock sine oscillator uses an uninterpolated 65k-point lookup table. Lookup tables are general purpose and somewhat brute force, however they not always the most efficient choice for a specific task.

Frequency and phase modulation can be easily implemented in direct evaluation schemes.

[MyCo]

Nice, keep on posting!

I used the "Reinsch Oscillator" for LFOs quite for a long time, never had problems with it. But didn't know that it's called that. I always thought, this is just a self oscilating filter, and someone accidently discovered that it can self oscillate very stable

@Martin: Have you checked how the drifting of your Oscs are compared to the stock Osc? I expect for the recursive Oscs, that they drift a lot faster.

Lately I switched for LFOs completely to a ramps system. Basically you have just a counter and pass that into converters for the given waveforms. That way it doesn't matter what source generates the LFO. That's the code I use as replacement for the "sin1()" code function:

Code: Select all

streamin angle;           
streamout out;
           
int ABSMASK = 2147483647;
float ONE = 1;       

movaps xmm1,angle;   
addps xmm1,xmm1;
subps xmm1,ONE;
movaps xmm0,xmm1;

addps xmm0,xmm0;
andps xmm1,ABSMASK;
addps xmm0,xmm0;

subps xmm1,ONE;
mulps xmm0,xmm1;
movaps out,xmm0;

[Exo]

Thanks Martin, great posts as always

I cannot wait to check this out when I am back at my machine

[tulamide]

Thank you Martin, for sharing your knowledge. I appreciate the generousity! I will read this thread with eagle eyes, since I'm especially interested in your explanations. Most other references always expect me to already be a qualified sound engineer. With the result, that I don't understand much
But you speak my language, so to say

[tester]

Hi Martin,

At some point, efficient and clean sine oscillators with accurate phase settings will be very useful here as well (can you add resync nodes somewhere too?), so this one should give some great boost.

I was wondering about one thing. Is it possible to make multi-sine oscillator (static, no modulation, perhaps individual phase offsets to each frequency), that would be more efficient than combining individual sine oscillators?

[martinvicanek]

Thanks guys, it is good to know that someone actually reads the stuff.
@MyCo: Indeed, a recursive oscillator is a filter driven to self-oscillation. With regard to drift, you can analyze those beasts theoretically and classify them as unstable or hyperstable, respectively. The unstable ones don't have their poles exactly on the unit circle in the z-plane, hence the amplitude runs away exponentially. That may start out very slow in the beginning, but ultimately the thing will blow up or collapse. The only way to tame these is to apply some gain control mechanism. The coupled form is one example for this class. The hyperstable ones, on the other hand, do have their poles exactly on the unit circle, hence there is no systematic runaway but only a possible drift due to roundoff errors in the iteration. That difference may seem subtle, but it is not. The oscillators in my schematic are hyperstable.

Yes, I did some testing and let them run freely for half an hour or so. The amplitude remained constant (deviation was less than 1e-4). However, I want to have a closer look, run longer periods and also record some statistics. Thanks for asking.

Yes, the ramp driven LFO concept has some nice features, and I like your stitched parabolas as a fake sine - absolutely legit for an LFO! We can take this up again when I post #4.
@tulamide, thank you, glad you find my explanations useful.

[martinvicanek]

Okay, so I did some more testing regarding drift of those freely running recursive oscillators, with some interesting results. Below is a log from an overnight run. The display shows the amplitude deviation from unity magnified by 1e+4, taking 1 sample each minute.

DriftTest1.png (17.99 KiB) Viewed 59547 times

The amplitude fluctuations are confined to a band of possible values, there is no growth or exponential runaway. I would have expected a random-walk-like deviation proportional to the square root of running time, however the oscillator seems to get trapped in a limit cycle instead. I found this behavior in all test cases in a wide range of initial conditions and input parameters. So this is good news.

@tester: I deliberately left out sync inputs because naive hard syncing causes terrible aliasing. I thought it is useless and only increases CPU load. Do you have a particular use for it? And yes, it is possible to create a multiple oscillator (straightforward code replication) however there is not much to gain to be expected in terms of efficiency compared to individual modules, no overhead that could be shared.

[KG_is_back]

The amplitude fluctuations are confined to a band of possible values, there is no growth or exponential runaway. I would have expected a random-walk-like deviation proportional to the square root of running time, however the oscillator seems to get trapped in a limit cycle instead. I found this behavior in all test cases in a wide range of initial conditions and input parameters. So this is good news.

This is good news indeed. And quite surprising too.

[martinvicanek]

(MV's Oscillators Part II)

Classical waveforms like a sawtooth feature a rich overtone spectrum. In an analog processing chain, this is no concern as any content above 20 kHz, say, can be easily removed by appropriate filtering. In the digital domain, however, frequencies above the Nyquist frequency get reflected back into the audible range – a well-known and generally unwanted phenomenon called aliasing. It is very hard to eliminate aliasing once it occurs, so the objective is to avoid generating frequencies above Nyquist in the first place.

There are a number of ways to generate band limited waveforms, each addressing a different balance between alias suppression efficiency, faithful waveform approximation, and computational load. Jussi Pekonen’s Seminar Lecture “Antialiasing Oscillator Algorithms for Digital Subtractive Synthesis” at http://legacy.spa.aalto.fi/u/jpekonen/t ... ekonen.pdf provides a good overview.

In this schematic I have chosen the so-called PolyBLEP method to generate band limited classical waveforms. (The acronym stands for “polynomial-based band-limited step”.) This method marks a sweet spot in terms of CPU efficiency and alias suppression: the typical CPU load is only about 10% compared to the stock oscillators. However, ultimately the sound is what counts, and that’s to some degree a subjective issue. So go and check it out!

Updates:
v1.1 - bugfix for negative frequencies/through zero FM.
v2.0 - bugfix for phase drift, included MyCo's additions