obscure antialiased saw code [Ancient thread bumped; see page 3]

[Paul Sernine]

A long time ago...
by the time I was a electronics student, one of our DSP teachers told us about synthesis and analysis of sounds. That was quite interesting and funny ... until he gave us an exam .
The code below was part of this exam. We had to reverse engineer and explain how this obscure code worked . It generates an antialiased saw sweep into a raw pcm 16 bit mono file.

Code: Select all

/* Obscure.c         Examen Partiel 2b
   T.Rochebois       IEF-UPS bat220
   02/03/98
*/
#include                              <stdio.h>
main(){double _                       =0,o=2.2675e-3,
  e1se =1.5759e12,                    doub1e=0,__1=0,f1oat
=0,l1_=0,l__=0,_1__=0,                _l_=0,_1_=0;short O;FILE
* fc1ose =fopen("saw.pcm",            "wb");for(;o< .3;__1=doub1e,
l1_ = f1oat,_1__ =l__,_1_=_l_,        fwrite(&O,1,2,fc1ose),_+=(o *=1+
2.267576e-6)){_-=2*(_>1);O=(e1se*=    1-9.070254e-6)*( _1_-(_l_=_1__-(l__=
l1_-(f1oat=__1 -(doub1e=_*(_*_*(_*_*3-10)+7))))));}fclose(fc1ose);}/*GENERATOR*/

Just try it, event if it is obscure, it is quite efficient.

[Music Engineer]

...i guess the point was the importance of good coding style?

[stefancrs]

it's not like it's HARD to de-obscure it. But it's tedious. And boring. And you'd still need to figure out what his different variables are representing

[texture]

And it will crash if it can't open the file.

[jupiter8]

Love the naming of the variables, f1oat fc1ose doub1e e1se

Pure genious!

[aciddose]

http://xhip.cjb.net/temp/nastylongcode.txt

and of course, look into the stl headers of any c++ compiler, that is always fun.

[duncanparsons]

its like e e cummings doing code...

DSP

[duncanparsons]

He's a good un-obfuscation of c code tho'..

http://www.thedailywtf.com/forums/60255/ShowPost.aspx

DSP

[aciddose]

i didnt bother mentioning it is a very simple implementation of an integration of a blit, where the functions are all aproximated. the results are poor and the cpu use is high when the resulting quality is taken into account.

the only notable feature is the lack of any requirement for conditionals and a constant cycle count. the problems of blit integration far outweigh any advantage, though.

[Paul Sernine]

i didnt bother mentioning it is a very simple implementation of an integration of a blit, where the functions are all aproximated.

That was not the interpretation given by rochebois. As I believe that such a simple code can be interpreted in many ways, I am very interested in your interpretation. Can you give details of your analysis.

the results are poor and the cpu use is high when the resulting quality is taken into account.

Did you tried it or just overlooked the code ?
I personaly use my good old cooledit pro to load the pcm and draw some spectrograms and I saw very low aliasing.

the only notable feature is the lack of any requirement for conditionals and a constant cycle count.

That's true, but I am not sure it is the only notable feature.

the problems of blit integration far outweigh any advantage, though.

Can you extract the bit of code that performs the "blit approximation" and the bit of code that performs this "blit integration" ?

[Fire Sledge - Ohm Force]

It's the 4th-order differentiation of a sampled, periodic, 5th-order polynomial function, giving a periodic ramp (sawtooth). The polynomial (here, approximating a sine) has a very steep harmonic slope (-5 * 6 dB/octave), as well as continuous derivatives. When it is sampled, aliased harmonics follow the same slope, so the ones occuring in the lower part of the spectrum are well attenuated. Then the spectrum is rectified with the quad differentiation to match a ramp. The aliasing level, at least in the lower part of the spectrum, is way better than the one given by a naive sawtooth generation, because sawtooth harmonics have a -6 dB/octave slope, hence the aliased content. It should give quite good results once oversampled.

However I think it's evil to voluntary obfuscate code for a DSP exam! http://xhip.cjb.net/temp/nastylongcode.txt looks more understandable.

[duncanparsons]

..you never quite know when to take them seriously..

Good to see some Ohm action around the forohm again

DSP

[Paul Sernine]

It's the 4th-order differentiation
...
, hence the aliased content. It should give quite good results once oversampled.

c'est net et sans bavures! It is as clear as water.
Thierry Rochebois' antialiasing technique is a variation/extension of the method described in

Modeling Analog Synthesis with DSPs
John Lane, Dan Hoory, Ed Martinez, and Patty Wang
Computer Music Journal, 21:4, pp31-41, 1997

They use |sin(x)| along with first order high pass filtering to generate their signals (they also add a "brickwall" filter instead of supersampling to limit the remaining aliasing).
Rochebois use polynomials instead and goes three steps ahead.

An interesting feature is that the resulting signal has no ringing
- in the spectral domain, it loses energy too fast in the high freq. That's unperfect antialiasing.
- it behaves quite well if soft-clipped. (if you soft-clip an optimaly antialiased but ringing waveform, you remove part of the ringing, hence, part of the "antialiasing").

The main drawback of rochebois's method is that it needs high precision arithmetics : derivation (i.e. high-pass filtering) accentuate numerical "noise" in the high frequencies.
doubles are necessary for 5th order polynomials.
with floats, you are limited to 3rd order polyn . But as Laurent stated, you can use (2x) oversampling (which is almost necessary if you perform distorsion and/or filtering).

As it is branchless, as acidose stated, it can be very easily SSEd .

[aciddose]

at first i had assumed it was derived from some blit integration code i had seen around the same time in 98. the output produced is extremely simmilar.

i have been unable to find the function to calculate the correct gain factor based upon frequency. the function most likely is more complex than the generator itself. that fact limits the possible use of such a signal generator severely. most of my code involves frequency changes per-sample. the imperfect results and ludicrous limitations of this code are the reason it isnt acceptable to use for any purpose outside academia, in my opinion.

a good blep implementation can produce better results (including lack of ringing) in less operations by average on any system capable of conditional execution. that means, all of the important ones.

[Fire Sledge - Ohm Force]

I played a bit with this oscillator and it has a big drawback. It may click when pitch is changed. So it is required to recompute the whole oscillator state under some conditions. The problem is that the state recomputation is quite slow (computing 4 times the polynomial + derivations on sampled data).

From tests I've done :
- Below 1/300 (osc freq relative to samplerate), it is always required to recompute state. That's 150 Hz @ 44.1 kHz.
- At 1/150, freq change must stay below 0.01 cent/sample to avoid state recomputation (10000 samples to go to the next semitone)
- At 1/50, limit is 0.3 cent/sample
- At 1/10, limit is 5 cent/sample

The sweep given in the example is very slow and unfortunately hides this matter.

-- Laurent