Aliasing Problems With Additive Synth

trogluddite · 9 Jan 2012

Hi Ollie, welcome to SM.

I think your last suggestion, muting the >(Sample Rate/2) oscillators would be the best way to go. Although it is rather counter-intuitive, there is no sure-fire way to remove aliasing distortion using filters - the aliasing is created within the oscillator algorithm itself, and will always occupy part of the (usually) wanted audio range.

Note that this assumes that all your oscillators are sine waves. If you use more complex waveforms for each 'component' of the sound, then aliasing can potentially happen at much lower fundamental frequencies.

OllieMarshall92 · 9 Jan 2012

University Tutor solved the problem for me, but if anyones interested you put this code in a code object:

streamin in;

streamout out;

out = (in <= 1.0) & (in);

Put the object just before the oscillator.

OllieMarshall92 · 9 Jan 2012

trogluddite, I was trying to make a square wave using just sine waves, so i know what you mean about aliasing occuring at lower fundamentals, that bit of code has solved my problem though 🙂

treacherousumbrella · 12 Jan 2012

OllieMarshall92 wrote: University Tutor solved the problem for me, but if anyones interested you put this code in a code object:

streamin in;

streamout out;

out = (in <= 1.0) & (in);

Put the object just before the oscillator.

that's not going to cure the aliasing, if anything that will make it worse

trogluddite · 12 Jan 2012

treacherousumbrella wrote: that's not going to cure the aliasing, if anything that will make it worse

Yes, I also have my doubts - in principle it will work, but only for certain very simple circumstances...

Setting the frequency to zero stops the oscillator's counter, so it no longer steps through the waveform, so there is no AC output. In the particular case of an SM synth, all oscillators initialise to zero at note on (hence free running oscillators are so problematic) - so no DC either. Effectively then, the oscillator is off - the oscillator code itself will still be running, but will just output repeated zeros.

The caveat is that it will sound pretty nasty if you start modulating the frequency - some oscillators could end up crossing the upper threshold at 1, and so start switching between running and not running. At the moment of turning off, the oscillator is locked at the current phase, so you get a DC offset - and when they turn on, the phase (relative to the other oscillators) is set at some arbitrary point, depending on how long it has been turned off.

The 'brick wall' threshold is set right at SR/2, and I doubt that many algorithms are perfect enough not to alias at least a little that close the Nyquist limit - and it will be intermittent as the oscillators turn on and off - as our perception is tuned to notice 'difference', that will draw attention to any artefacts.

I would be tempted instead to put something like this in series with each oscillator's output...

streamin Oscillator; streamin Frequency; streamin RollOff; streamout Out;

float Gain;

Gain = RollOff * (1-Frequency); Gain = max(0,min(1,Gain)); //keep in 0-1 range! Out = Oscillator * Gain;

So, as the frequency of the oscillator approaches one, its gain is turned down, until at the Nyquist frequency it is silent. The RollOff parameter (values significantly greater than one) sets the steepness of the slope, and the steeper the slope, the smaller the band of frequencies affected (because of the min). As well approaching Nyquist more gently, this will also prevent any switching artefacts, have no DC offsets, and retain the phase relationships of the oscillators - even when modulated by pitch bend, LFOs etc.

It is still pretty crude, and it may be that a 'curved' gain slope may sound better - but that would cost more CPU cycles.

Good luck with the project, by the way - it's always nice to see folks get outside the 'comfort zone' of 'me too' subtractive synths. 🙂