Start to Finish: A Story of Resampling

Resampling is such a wonderful concept. The idea of taking an audio stem, processing it, processing it again, and then again (and so forth) is a very attractive one to me, since you are not constricted by how much RAM you have. All you need is a fast enough CPU to render things offline in a decent amount of time.




Using (mostly) csound for processing audio files, I tried doing some resampling myself, and I was quite pleased with the end results. This recording below shows the sound in the various phases of development:


Here were the steps involved:

Step 0: Create an instrument:
I made a very simple Karplus-Strong instrument in csound using the pluck opcode. This instrument was sampled and converted to a Milkytracker *.xi instrument using a tool I wrote.

Step 1: Sequence a melody:
Using my sampled csound instrument, I wrote out a short melody inside of milkytracker. 

Step 2: Render the sequence:
The melody sequenced in milkytracker was converted to a csound score file using a tool I wrote. This score file was then rendered in csound to create a high-quality version of the sequence.

Step 3: Reverse
The audio file from Step 2 is then reversed using a free command-line utility called sox.

Step 4: Reverb
The reversed melody is put through reverb in Csound using the reverbsc opcode. The audio file is extended to preserve the massive reverb tail.

Step 5: Waveset
The reverbed audio file is sent through Csound again, this time using the waveset opcode. This opcode timestretches the audio by looping a waveform at two zero crossing points N number of times.


The big picture:
This little experiment is was a product of a little tool I'm working on called SoundPipe, which will be a perl module that will allow you to create scripts that will non-destructively resample audio files. A little bit like SoundHack, only more DSP options using Csound...

Csound Mini-Lesson 3: Kicks in Csound

Kicks are the heartbeat in music. A wonderful pulse that gives music liveliness. In electronic dance music, it is the most important aspect of a track.

There is more than one way to make a kick synthetically. I'm going to show you the way I make my kicks.

By the end of this tutorial, you'll be able to make kicks that sound like this:



So, let's get started!

PART 1: the "boom"

The first part of our kick will be what I call the "boom" of the kick. This is the main part of our kick. To make this, we will start of by putting a 60hz sine wave through an exponential envelope:

gisine ftgen 0, 0, 4096, 10, 1
instr 1   
kenv expseg 1, .6, 0.0001
a1 oscil .9*kenv, 60, gisine
outs a1, a1
endin

This is known in the industry as an "808" kick (though I highly doubt this is how it actually was done on a tr-808.) Useful for layering, but there isn't enough body for a main kick. What I do is create a line which goes from a little over 60hz to a little bit under 60hz. If done very quickly (under 500ms), this can be perceived as a percussive sound:

gisine ftgen 0, 0, 4096, 10, 1
instr 1   
kdrop linseg 120, .2, 40
kenv expseg 1, .6, 0.0001
a1 oscil .9, kdrop, gisine
outs a1*kenv, a1*kenv
endin

This sounds a lot better! If your music is a sparse, this might be a good stopping point. If not, you may need to add a some click. You may also notice that instead of applying the amp envelope at the oscil opcode, I applied right at the output. Since all we are doing is scaling a signals frequency, both places work!

PART 2: the "click"

Another aspect of a kick is it's click. This high frequency content will define the attack of the instrument. To make this, we will take a white noise generator and put it through a very fast envelope. I played around a little bit with balance and changed some routing:

gisine ftgen 0, 0, 4096, 10, 1
instr 1   
kdrop linseg 120, .2, 40
kenv expseg 1, .6, 0.0001
arand rand .05
kclik linseg 1, 0.004, 1, 0, 0
a1 oscil .9, kdrop, gisine
aOut = (a1 + (arand*kclik))*kenv
outs aOut, aOut
endin

Here is a line-by-line play of our final kick, bottom to top:

"endin": the instrument end tag.

"outs aOut, aOut": send the audio signal aOut to our left and right speakers.

"aOut = (a1 + (arand*kclik))*kenv": Mixing our click and boom together. Order of operations matter here. (arand*kclik) is our click. we are taking our white noise and multiplying it by our fast envelope. a1 is our boom. We are combining our boom and click together and then multiplying that by one envelope. This makes it sound more unified.

"a1 oscil .9, kdrop, gisine": Our oscillator creating our "boom." Amplitude of 9, linear envelope modulating pitch, f-table referencing sine.

"kclik linseg 1, 0.004, 1, 0, 0": This is our very fast envelope (4ms) that will make our click.

"arand rand .05": white noise generator.

"kenv expseg 1, .6, 0.0001": exponential envelope which will shape the amplitude of our kick.

"kdrop linseg 120, .2, 40":  linear envelope which quickly jumps from 120 to 40 hz.

"instr 1": instrument begins. it has an ID of 1

"gisine ftgen 0, 0, 4096, 10, 1": our generated sine wave in an f-table. has a global i-rate variable called "gisine."




And there you have it!

Envelopes, Noise, and "Snares"

 Tutorial 2: Making simple EDM snares.

If your song has a beat, your song is going to have a snare. Why not try to make one yourself? Lets make some ridiculously simple snare sounds in Csound!

The concept of our synthesized snare is quite simple: take a noise source and put it through an envelope with a fast transient. You can do this on just about any synthesizer. With Csound, you can get a little bit more specific what the noise source is and what kind of envelope it is. For this example, we will be showing two different sounding envelopes and noise sources, with a total of 4 combinations.

Envelopes: Linear vs. Exponential

Envelopes are huge, especially when you are dealing with times that are smaller than half a second. An envelope with an attack time of 10ms is going to have completely different character than that of of a sound with an attack time of 100ms.

Even more drastic than the time it takes to move from point to point is how it moves to that point. In Csound, envelopes can either be linear or exponential.

A linear envelope for our snare could look like this:

    aenv linseg 1, .2, 0

The opcode called linseg is producing an envelope that linearly goes from 1 to 0 in .2 seconds. The output of this opcode is going to the audio-rate variable aenv.

An exponential envelope for our snare could look like this:

    aenv expseg 1, .2, 0.0001

The opcode called expseg is producing an envelope that exponentially goes from 1 to 0.0001 in .2 seconds. Note that 0 can’t be used in an exponential curve.

Csound’s white noise generator:
    Csound has many random number opcodes. One of these opcodes can produce random numbers at an audio rate and produce white noise:

    anoise rand .8

The opcode called rand is creating random numbers between the values .8 and -.8 to anoise. If we send anoise to our speakers, we will get white noise at 80% full scale (assuming 0dbfs=1.)

Using FM aliasing as a noise source:
    We can create very unusual sounding aliasing sounds with an FM oscillator with an absurdly high modulation index. The result is noise. But it is meaningful noise:
    gisine ftgen 1, 0, 4096, 10, 1
    afm foscil .5, 100, 1, 1, 100000, gisine
Instead of wasting space explaining what each opcode does, I suggest you check out the entry in the Csound Manual. It is a resource should never be without when working in a language as vast as Csound. Learning how to read from this manual will help you learn Csound on your own. If you are lost on what exactly a carrier or modulator or modulation index is, you can read up about it here.

It’s quite simple to put the sound and the envelope together in an orchestra file:

instr 1
iamp = p4
a1 rand iamp
aenv expseg 1, p3, 0.001
outs a1*aenv, a1*aenv
endin

This produces a pretty common snare patch. You’ll notice I’ve made the amplitude and length parameter values so I can control them from the score like this:

i1 0 .4 .6

The duration is .4 seconds and the amplitude is 60%. Play around with duration and see how the exponential envelop shapes the sound.

Offline vs. Realtime rendering:

Csound was originally intended for offline rendering, as computers at the time had the computing power of a 10 calculator you’d buy at CVS. You’d write your Csound patch run it, and come back the next day to hear what it sounded like. Offline rendering is very useful for generating samples that you can then import into a DAW. Simply running csound from the commandline with no flags will give you a file called test.wav (or test.aif on a mac):

csound filename.csd

You can specify the output file you want with -o

csound -osnare.aif filename.csd

If you are on a Mac, files will be rendered as an AIFF file regardless of extension (unless you specify the kind of audio file you want.) Conversly, PC and Linux files will render to wav files, regardless of the extension they have on it.

For the sake of brevity, I have put the rest of today’s files onto github. You can download the file here. You’ll find 4 separate instruments, each utilizing a different envelope and noise source.

Next week, we will be building a supersaw lead sound in Csound.







https://github.com/zebproj/csdfiles/blob/master/snare.csd

Tutorial 1: The CSD structure, and beating frequencies

Today, we will make some beats with Csound. 

Text editors and/or frontends for Csound will not be discussed much, but they are required to run Csound. I personally write up everything in VIM, and then use Csound from the command line. Much information is available on the various tools you can use. Go explore. Don't worry, my examples should work. 

Csound has two main sections. The orchestra is the section that makes the sound, and the score is the section that tells the orchestra what to play.  These two sections used to be two separate files (eg: song.orc and song.sco) back in the day, but now they consolidated into one file with an extension of *.csd. 

A CSD is an XML file. Open up a new file and type this:

<CsoundSynthesizer>

<CsOptions>

</CsOptions>

<CsInstruments>

</CsInstruments>

<CsScore>

</CsScore>

</CsoundSynthesizer>

To break it down:

1. everything is in encapsulated between <CsoundSynthesizer> and </CsoundSynthesizer>

2. everything between <CsOptions> and </CsOptions> will set command line flags.

3. everything between <CsInstruments> and </CsInstruments> will hold the orchestra

4. everything between <CsScore> and </CsScore> will hold the score.

The first thing we will do is make a header inside the <CsInstruments> tags:

<CsInstruments>

sr = 44100

ksmps = 1

nchnls = 2

0dbfs = 1

</CsInstruments>

Basically, we are telling Csound that we want a project with:

a sample rate 44.1khz (sr), 

a control rate which matches the sample rate (ksmps), 

stereo audio (nchnls),

and range of loudness where 0 is no sound, and 1 is full-scale digital audio (maximum loudness). 

There's no real need to know exactly what these things do right now. Just know that we will be using this almost all the time in every example we have.

We will now make an instrument which produces a simple sine wave, right below the header we made. Do not copy and paste. Type it:

<CsInstruments>

sr = 44100

ksmps = 1

nchnls = 2

0dbfs = 1

gisine ftgen 0, 0, 4096, 10, 1

instr 1

a1 oscil .4, 100, gisine

outs a1, a1

endin

</CsInstruments>

Here is (basically) what is happening, line by line:

1. a variable called "gisine" which makes a sine wave. this is outside of the instrument.

2. the instrument starts. it has an instrument ID of 1.

3. oscillator module using the oscil opcode. It has an amplitude of .4, and a frequency of 100. it is reading the sine wave from the variable "gisine." the audio information is being sent to a variable called "a1."

4.  We send the audio from the oscillator (a1) to the stereo speakers.

Now that we made the instrument, we need to instruct Csound to play it. In the <CsScore> section of our CSD file, add this:

<CsScore>

i1 0 4

</CsScore>

This is our score. As I said in the last post, it is only a text table. Each value is called a parameter value, or p-value:

p1 ("i1") tells us that we want instrument 1 to play a note.

p2 ("0") tells us that we want to play a note right when we compile (0 seconds after performance starts).

p3 ("4") tells us that we want to hold the note for 4 seconds. 

If you are going to run Csound from the commandline, you need to tell Csound to play the file in realtime and not render it to an audio file. Add this to the <CsOptions> section:

<CsOptions>

-odac

</CsOptions>

Now run it!

If you got a sinewave, good. If not, check the terminal output and see if there are any error messages. Typos and syntax errors are very common. 

Supposing that we want to control pitch from the score. We can use this by adding additional parameters and p-values. We can modify our instrument like so:

gisine ftgen 0, 0, 4096, 10, 1

instr 1

a1 oscil .2, p4, gisine

outs a1, a1

endin

We can now declare the frequency of our oscillator in the p4 slot in our score:

i1 0 4 100

Does it have to be 100hz? nope. It can be 101, 200, 1000, 20000, 1.41760hz, or any numerical value. Lets have a little bit of fun by making some "beats" by using this as your score:

<CsScore>

i1 0 4 300

i1 0 4 301

</CsScore>

Two or more simultaneous tones with similar frequencies will clash with one another. Here we have a 300hz sine and a 301hz sine. The farther apart they are, the faster they get. Try changing 301hz to 305hz.

Harmonic beats, though simple, can be kind of fun. Try running this as your score:

<CsScore>

i1 0 16 300

i1 0 4 305

i1 4 4 308

i1 8 2 310

i1 10 2 308

i1 12 4 305

</CsScore>

Figure out what each line is doing. What is their frequency? When do they start? how long do they stay on? Try making your own scores from sine waves. Remember that things get louder when you start adding sine waves together. Turn the volume down and be careful with your ears!

What is Csound, why it sucks and why it rocks

I'm going to try to make a few mini-lessons here on Csound. We'll see how this goes.

I'm assuming that you have never used Csound before, so I'll start from the beginning. 

Csound can be thought of as a text-based modular synthesizer. Synthesizers are "built" inside of a text editor using modules called opcodes. Modules include various kinds of oscillators, filters, LFOs, and envelopes, but there are more unique opcodes for things like physical modeling, granular synthesis, additive resynthesis, and phase vocoding. There are ways to implement programming idioms, but Csound is not a programming language. This is a tool for musicians and musically-minded individuals, not a way for programmers to incorporate musical elements into their work. 

I learned about Csound 4 years ago, and have been using it quite intensely the past year and a half. It is one of my most used programs for synthesis and sound design. 

To start things off, I'd like to give four reasons why Csound sucks and is a terrible program to use:

1. It's old. The source code is an accumulation of over 20 years of work. It can be very difficult to incorporate Csound seamlessly with modern tools in a DAW. It has quirky old-timey conventions.

2. The score. It's a terribly old-fashioned text table with timings and other information which Csound will use to play instruments. Writing out note-sequences can be very time-consuming, and can be done much quicker in a DAW. 

3. The orchestra. It's basically the section of a Csound synthesizer where you build the synthesizer. It's only text, so it can be very hard to read at times. It's very hard to come up with sounds quickly in Csound, since they are typed out and not "patched" or "twiddled."

4. Everyone in the Csound community makes strange music that's hard to listen to. It's rare that you find a (good) Csound composition with a beat, something in 4/4 time, or even something with western tonality! To me, the stereotypical Csound composition is droney, with shrill blips and scary clusters of notes. 

Conversely, I also would like to give four reasons why Csound rocks and is an incredible tool for electronic music:

1. It's old. Not only that, but the community is very fervent on backwards compatibility. Csound compositions written twenty years ago can still run flawlessly on the most recent version of Csound. In the electronic music world, it is very typical to have to learn new software every 5 years or so, and to essentially lose any projects made with the older software (backwards compatibility is not a guarantee.) You take the time to Learn Csound, and your projects will be timeless.

2. The score. it's only a text file. One can very easily generate scores for your instruments in any programming language with file I/O (which is basically every modern programming language.) Your scores are not bound by the constrictions found in a MIDI sequencer. I'll get more into this later, but things like audio-precise timing and floating point resolution parameters. 

3. The orchestra. It forces you to think at a very low level for sound design. Working with Csound, you will gain expert knowledge on how to make engaging and unique sounds with synthesizers. As an added bonus, this can be applied to any available commercial synthesizer. 

4. Everyone in the Csound community makes strange music that's hard to listen to. And that's a good thing. There is so much easy music out there. Hard music is food for your brain. As a musician, it's the hard music that makes you grow. 

A month of Generation

I've always loved the idea of generative computer music. I appreciate it with the same kind of wonder that I do with trees. They both start out a tiny little acorn which you plant in the ground. You give it time and it grows, twisting and turning in beautiful ways that you'd never expect.

I really want to get a firmer grasp on composing generative music, so I will try to write one very short piece of generative music a week for 4 weeks. Finals and such are totally going to muck this up. I can already tell...


Anyways, here is my Week 1 composition. This one basically utilizes the fibonacci series to determine what notes to play.  There are a total of three voices, each being played by a simple 1:1 FM instrument with linear decay.




Composition is looped based, so the same algorithm is used more than once within the piece.

Blender and Csound

Allow me to show you a video I made a few days ago:
What you probably saw was a nine second video of a 3d computer animation of a purple cube striking a gold platform of sorts. If you had your speakers on, you would have also noticed a ringing sound happening every time the cube touched the platform.
The video itself is pretty lame and boring, but the idea behind is actually something I've been thinking about doing for a while.
What is happening
The video above has two separately created components: a video track and an audio track. The audio track was rendered using Csound, reading instructions on what notes to play from a something called a score file. This same set of instructions was read and interpreted by another piece of software called Blender, which then produced the visual part you saw above.

The steps
While there is probably a much more efficient way of going about this, this is the process I used to produce this animation. My computer programming knowledge is pretty sparse, so I go with what I know will work.
1. Write/Generate a Csound Score. (In this case, the score was generated with information regarding instrument number, start time, duration, pitch, and amplitude)
2. Render an audio file with the created score file in Csound. Make sure the samplerate is set to 48khz
3. Format the score file so that there are only i-statements. In other words, make the score file as simple as possible. (This was done using a short python script)
4. Parse the reformatted score file and generate a new file readable by Blender. In this case, it is a file with a bunch of lines saying dobounce(x,y) where x is the time of the strike, and y is the release. The parser was written in C to take advantage of the fscanf command.
5. Paste these new instructions in a Python script, which will be able to read them and directly work with Blender.
6. Run the Python script + generated score instructions inside of Blender. This will automatically create the necessary keyframes for the animation.
7. Render the animation to a video file.
8. Take the video file and the audio file and sync them together using mencoder. Since the audio is at 48khz, the audio and video should (hopefully) sync up perfectly.

And that is all there is to it!

Why this is so cool


This is a really cool breakthrough for me for a number of reasons. The biggest reason is because I finally figured out a way to incorporate visuals into my music in a simple, but complex way. Unlike most visualizers which take simply amplitude information from an audio file, mine took individual note information and parameters to render visuals. I just used start time and duration for animation parameters, but the possibilities are virtually endless! I believe visuals are especially important for 21st century music. Many times, the music is so out of touch with an average listener that it can be helpful to have a video to explain what the music is doing in order to gain a further appreciation of what is happening.

The second reason why I like this project so much is that it uses entirely open source software. Csound, Python, Blender 3d, and C are all under some sort of GPL or Creative Commons liscense. If there is anything that I want to stress in this blog it is this: the open source platform is the future of digital audio technology. I will repeat myself: the open source platform is the future of digital audio technology.