Synth Articles
category: code [glöplog]
Hello again,
I would like to ask for some synthetizer programming articles. Where I can find it? Sorry for the small and quick request.
Thanks in advance
I would like to ask for some synthetizer programming articles. Where I can find it? Sorry for the small and quick request.
Thanks in advance
How about making "micro-chords"?
like the three wires with ever so slightly different tunings struck by a single acoustic piano key
tldr
like the three wires with ever so slightly different tunings struck by a single acoustic piano key
tldr
Oh, I forgot about this article here
"It struck me that, at least in theory, organ pipes should generate quite primitive sound waves. If so, how come a church organ doesn't sound like a chip tune, which is also built up from simple waveforms? Well, actually it will, if you remove the church. And if you connect a Commodore 64 home computer to a loudspeaker in a large hall, it will sound like an organ."
"It struck me that, at least in theory, organ pipes should generate quite primitive sound waves. If so, how come a church organ doesn't sound like a chip tune, which is also built up from simple waveforms? Well, actually it will, if you remove the church. And if you connect a Commodore 64 home computer to a loudspeaker in a large hall, it will sound like an organ."
Nice quote. :)
Thanks for the responses.
What about the guitar synthesys implemented here?
It isn't simply the Karplus-Strong algorithm. It really sounds realistic. My DSP knowledge isn't enough to model something like this by myself.
Thanks for the responses.
What about the guitar synthesys implemented here?
It isn't simply the Karplus-Strong algorithm. It really sounds realistic. My DSP knowledge isn't enough to model something like this by myself.
This is not what you asked for, but it could be helpful either way:
http://www.soundonsound.com/sos/allsynthsecrets.htm
http://www.soundonsound.com/sos/allsynthsecrets.htm
Danguafer:
Actually that is a karplus strong implementation with some tweaks and some filters - a while ago I disassembled the complete swf-thingy and reimplemented it in C.
Actually that is a karplus strong implementation with some tweaks and some filters - a while ago I disassembled the complete swf-thingy and reimplemented it in C.
This is what it sounds like - not 100% like the flash thingy... but close enough http://research.mercury-labs.org/record.ogg
(And I guess I screwed some parameters up... :))
The only article published in Hugi which has the substring "synth" in its headline is Recursive sound wave synthesis in Hugi 22... If somebody likes to write an article on the topic, we are ready to publish it.
I still want to know where kb has dig out his oscillator algorithms ... I know how they work, but I really wanna know where he got those from :D
Which ones? The basic oscillators were straight floating point implementations of simple DCOs, and the box filter "antialasing" was actually something I thought of myself. Figured calculating the integral of piecewise defined linear functions couldn't be _that_ hard (and it worked pretty well, especially because in the final asm implementation I was able to shift together a 3-bit value from various status bits that then identified which of the 6 possible per-sample piece configurations had to be calculated. Enter a jump table, a few float instructions, and voila :)
Regarding the string synthesis above - the trick is not to have a schmancy-fancy string algorithm (ok, correct multitap FIR interpolation for the delay line feedback won't hurt a bit) but to model the excitation waveform and the body correctly. Strings are simple waveguides and in fact exactly as simple as they sound. The way a guitarist's finger strikes the chords isn't tho.
In fact that applies to most of synth programming - the algorithms are really simple; it's completely about how you use them. I can't stress that enough: Never develop a synth without an at least somewhat experienced musician nearby (be it yourself or a close friend), and after you nailed down the code, spend some time to write an interface that's actually fun to use and invites people to mess around. That's where good sound comes from, not from strict buzzword compliance.
Regarding the string synthesis above - the trick is not to have a schmancy-fancy string algorithm (ok, correct multitap FIR interpolation for the delay line feedback won't hurt a bit) but to model the excitation waveform and the body correctly. Strings are simple waveguides and in fact exactly as simple as they sound. The way a guitarist's finger strikes the chords isn't tho.
In fact that applies to most of synth programming - the algorithms are really simple; it's completely about how you use them. I can't stress that enough: Never develop a synth without an at least somewhat experienced musician nearby (be it yourself or a close friend), and after you nailed down the code, spend some time to write an interface that's actually fun to use and invites people to mess around. That's where good sound comes from, not from strict buzzword compliance.
Thanks kb, that's what I always wanted to know ;)
So I will think about your 'antialising' stuff a bit, because I really wanna get rid of my bandlimited wavetables^^
So I will think about your 'antialising' stuff a bit, because I really wanna get rid of my bandlimited wavetables^^
I'm going to thump down #ponce's book suggestion. It's frustratingly superficial, you wont be able to implement anything after reading it. I guess it's ok as a list of things to research somewhere else.
C64 in a church... sounds familiar... :D
I have dafx too and must admit that i learned more from musicdsp.org
Regardless of how much practical details there are in DAFX I have to say that I was quite inspired by the book. I think it's a very interesting read.
You need to know a bit about signal processing, z-transforms etc, for DaFX to be maximally useful. It contains some nice info, though, even if you don't know your poles from your zeros.
Quote:
You need to know a bit about signal processing, z-transforms etc, for DaFX to be maximally useful. It contains some nice info, though, even if you don't know your poles from your zeros.
Absolutely! It's by no means a beginner's text or a practical guide. But if you have that groundwork covered it can be useful and interesting :).
Let me ask a question about filters.
If I'm not wrong, it's implemented using FFT, right? I'm kinda lazy these days to take some time to understand the math behind FFT. I cannot even get an easy-to-understand text about it.
If I'm not wrong, it's implemented using FFT, right? I'm kinda lazy these days to take some time to understand the math behind FFT. I cannot even get an easy-to-understand text about it.
Some filters are implemented with FFT, but most are not. Converting between the time and frequency domains tends to introduce some inaccuracies.
Danguafer:
There are FIR (finite impulse response) filters, where the output is a weighted sum of the present and past input values.
These are always stable but they need to be quite long, e.g. m > 20. They're only used in special circumstances (almost never in synths).
Then there are IIR (infinte impulse response) filters, where the output is a function of the previous outputs and inputs
A regular second order resonant lowpass filter, i.e. 12dB per octave, as you might know from synthesizers, can be implemented as an IIR filter with m=2,k=2.
Larger filters (higher order) are generally built by putting these second order sections in series.
The 'a' and 'b' coefficients can determined by the formulas in Robert Bristow Johnson's EQ cookbook.
It is common to write the above IIR formula in its z-transformed version:
The z^-1 denotes a delay by one sample, z^-2 is two samples.
If you're familiar with complex numbers, calculating the frequency response is straightforward using the z-transformed version. Simply substitute exp(j*2*pi*f/fs) for 'z' in H(z) and calculate the magnitude of the resulting complex number, where fs is the sampling rate, f is the frequency 0..0.5*fs.
If you're using C++, check out std::complex<float>().
There are FIR (finite impulse response) filters, where the output is a weighted sum of the present and past input values.
Code:
y(n) = b0*x(n) + b1*x(n-1) + b2*x(n-2) + .. + bm*x(n-m)
These are always stable but they need to be quite long, e.g. m > 20. They're only used in special circumstances (almost never in synths).
Then there are IIR (infinte impulse response) filters, where the output is a function of the previous outputs and inputs
Code:
y(n) = b0*x(n) + b1*x(n-1) + b2*x(n-2) + .. + bm*x(n-m) - a1*y(n-1) - a1*y(n-2) - .. - ak*y(n-k)
A regular second order resonant lowpass filter, i.e. 12dB per octave, as you might know from synthesizers, can be implemented as an IIR filter with m=2,k=2.
Larger filters (higher order) are generally built by putting these second order sections in series.
The 'a' and 'b' coefficients can determined by the formulas in Robert Bristow Johnson's EQ cookbook.
It is common to write the above IIR formula in its z-transformed version:
Code:
Y(z) b0 + b1*z^-1 + b2*z^-2
H(z) = ---- = ------------------------
X(z) a0 + a1*z^-1 + a2*z^-2
The z^-1 denotes a delay by one sample, z^-2 is two samples.
If you're familiar with complex numbers, calculating the frequency response is straightforward using the z-transformed version. Simply substitute exp(j*2*pi*f/fs) for 'z' in H(z) and calculate the magnitude of the resulting complex number, where fs is the sampling rate, f is the frequency 0..0.5*fs.
If you're using C++, check out std::complex<float>().
No snappy comebacks, eh..?
I was thinking to reply after analyzing and implementing your reply. But I'm somewhat busy, sorry. Anyway, thanks for the explanation, it was very clarifying.