Csound Blog: Touch-Tone DTMF Generator

The Csound Blog
Issue #13

Most people would never think of a touch-tone phone as being an additive synthesizer. Though it may be primitive, a phone does generate tones using two sine wave oscillators, which in my humble opinion, qualifies it as such.

However, I’m not here to debate the semantics of whether or not a phone is a synthesizer. Instead, I’m here to demonstrate how easy it is to emulate the sounds of the touch-tone phone.


  • DTMF
  • macros
  • additive

More at The Csound Blog. For more information about Csound, please visit cSounds.com.


The Csound Blog
Issue #12

Today’s blog is on SineBox: a “music box” like instrument that plays itself. Once a user starts SineBox with a single i-event in the score, SineBox creates instances of itself, generating multiple sine tones over time. This may not be the most musical piece of Csound technology ever conceived of. It can, however, be molded to fit a wide range of uses, musical and otherwise.


  • P-Fields
  • if
  • schedule

More at The Csound Blog. For more information about Csound, please visit cSounds.com.

The Infamous mcseq

The Csound Blog
Issue #11

I want to learn morse code. I don’t know why, I just do. So a few days ago, I made it my new year’s resolution. The first action I took to help me accomplish this goal of mine was writing the Csound instrument Morse Code Sequencer Event Generator, or mcseq for short.


  • Morse Code
  • Event Generators
  • Sequencers
  • String Parsing

More at The Csound Blog. For more information about Csound, please visit cSounds.com.

Modular Instruments Part II

The Csound Blog
Issue #10

In the previous blog, “Modular Instruments“, I presented an instrument design model that takes advantage of Csound’s modular nature by breaking the common instrument structure apart into three elements: Synth Engine, Memory and Interface. (SEMI)

In todays blog, I create a new synth named MonoSynth based on the original SEMI Simple synth by replacing the zak memory with a memory core based on the chn opcodes, extending functionality of the engine, introducing modulation parameters, and by incorporating a method that links instances of instruments into an audio chain from within the score.


  • Modular Design
  • chn
  • Memory
  • Signal Routing
  • Modulation Instruments

More at The Csound Blog. For more information about Csound, please visit cSounds.com.

Modular Instruments

The Csound Blog
Issue #9

When designing a virtual instrument in csound, the easiest approach is to create a single self-contained instr. Within this instr, any number of opcodes can be arranged in a near-infinite number of combinations. Each instance of the instr manages its own local memory space/variables/signals. Users customize the interface of the instr by utilizing p-fields.

With this fundamental model of instrument design, it is already apparent that Csound excels in terms of modularity. However, there are many other approaches that expand this concept even further.


  • Modular Design
  • Interface
  • Memory
  • Synth Engine
  • Control Instruments
  • Zak
  • Macros

More at The Csound Blog. For more information about Csound, please visit cSounds.com.

Home Brewed Convolution

The fifth Csound Blog entry is up.

“According to wikipedia, convolution is ‘a mathematical operator which takes two functions f and g and produces a third function that in a sense represents the amount of overlap between f and a reversed and translated version of g.’ However, this explanation tells us little about convolution as applied to audio…”

Topics covered:

  • Convolution
  • Impulse Response
  • Reverb
  • Filter

More at The Csound Blog. For more information about Csound, please visit cSounds.com.

Robot Voices and Android Grooves

The fourth Csound Blog entry is up.

“One of my earliest synthesizer fascinations was the robotic voice produced by band vocoders. While in college, I stumbled across the vocoder schematics in The Computer Music Tutorial by Curtis Roads. Equipped with only Csound and my new-found knowledge, I created my first vocoder instrument. I have since designed many variations, and will likely to continue doing so for many years to come. Because robots rule…”

Topics covered:

  • Band Vocoder
  • Envelope Follower
  • Speech Synthesis

The Csound Blog

Back in the ADSR

Download thumbuki20061227.csd

One goal I have for these blogging explorations is to regularly refine my coding practices.   Starting with today’s entry, I’m enumerating my instruments with multiples of 10, a technique I’m borrowing from my Commodore 64 BASIC days.

The reason being I’m designing instruments that feed information into one another.  Events in Csound are processed from the lowest instrument to the highest, so the order matters.

By spacing out instruments, extra headroom exists for inserting instruments later, without having to go through the trouble of re-labeling existing instruments and score events.  At least, that’s the working theory.  More hands on experience is necessary before I know whether or not this will work in practice.

    10 PRINT "@!#&! YOU"
    20 GOTO 10

     * A typical BASIC program, often found running on store computers
     in the 1980’s.

Every once in awhile, an opcode that’s been sitting in the manual waiting to be discovered leaps from the screen and smacks me square in the face.  Csound is full of surprises like that.  For eight years, the schedule opcode has been completely ignored by yours truly.  Much like me to the ladies in high school, it’s as if it didn’t exist.  I must say, this is an opcode with near infinite potential.  In today’s example, I’ve utilized schedule to design a quirky little ADSR patch that is built using three instruments:  instr 10, 20 and 30.

Here’s the run-down.

instr 10 is instantiated in the score.  instr 10 is responsible for the attack-decay-sustain portion of the envelope.  The envelope stream is sent over a k-rate zak channel, chosen by user defined opcode ZakEnvAssign.  instr 10 schedules two score events.  The first is an instr 20 event, which begins at time p3, coinciding with the moment instr 10 finishes.  This is the release portion of the envelope.  The second schedule instantly instantiates instr 30.  The duration is calculated by summing instr 10’s p3 duration with the release time.  instr 30 is the sound engine module and sends resulting audio to the Main Mixer, instr 200.

Although this instrument is split into three, the composer only needs to worry about enacting it in the score with instr 10.  The rest is automated.

I’m utilizing one extra p-field in the score for demonstrating a varietal of release times.  The nice thing about this designs handling of the release, that even if the original p3 duration of instr 10 is shorter than the time it takes to finish the attack and/or decay portion of the envelope, the release will still function properly, without clicks or pops, by using the final value of instr 10’s envelope before entering the release stage.  *breath*

Another technique I’m exploring is using the opcode opcode to automate the distribution of zak channels.  For every instance of instr 10, my user defined opcode ZakEnvAssign designates a k-rate zak channel.  The mechanism used to choose the channel is a basic rotary switcher.  When ZakEnvAssign is called, the envelope is assigned the zak channel stored in  macro value ZKENVCURRENT.  ZKENVCURRENT is then incremented by one.  If ZKENVCURRENT is greater than ZKENVLAST, it is then set to ZKENVFIRST.  Once again, the macro system has proven to be both a time saver and a wonderful way to manage the zak channels.

And I was hoping this blog entry would be shorter than the last.

Visit: The Csound Blog

An Experiment in Csound Blogging

download: thumbuki20061222.csd

Welcome to my first blog entry that is simulcast both at thumbuki.com and within a Csound file. This is a personal blogging experiment. Often times, I’ll finish a Csound file that isn’t a composition, nor a bank of instruments, but more like a personal exercise or proof-of-concept. I never distribute these files because, as is, they aren’t really helpful to anybody. Perhaps by embedding a blog entry, these files will be placed into proper context, and allow them to be useful for others in the community.

I took an extensive break from Csound. By extensive, I mean years. I have recently returned to my computer music roots, with a fresh mind and new-found enthusiasm. I wouldn’t say I’ve forgotten much while on hiatus. In fact, I’m finding it’s much like riding a bike. However, I’m still without practice, and am in need of some serious honing.

Despite being something I’ve always wanted to do, I’ve never gotten around to synthesizing drums. I figured this was as good a time as any to tackle this subject. I found two places on the net that were uber-helpful. The first being Hans Mikelson’s Csound magazine articles (article 2). The second being Sound on Sound: Synth Secrets. Between these two sources, I ended up with the four electronic percussive instruments.

The other thing I wanted to do was to take a new approach to tackling Csound instruments. Traditionally, I’ve had my individual instruments write directly to the audio stream. However, I’ve been aware of the advantages of using the zak opcodes for mixing for years now.

In this file, I use two mixers. The first is a drum mixer. The four drums instruments produce mono-streams. These streams are sent to the drum mixer, via zak, where their relative amplitudes are set, placed into a stereo field, and sent to two zak audio busses. The second mixer reads the corresponding left and right zak channels, amplifies them, and sends the audio to the dac or file.

I experimented with two more zak-related techniques. The first is using a dedicated lfo instrument that writes to a zak k-rate channel. In this example, I implemented four synced LFOs, each featuring a different waveform. Including a sine, triangle, saw-down and square wave. Each waveform is assigned a unique k-rate zak bus. I’m using only one of the LFO channels, to modulate the frequency of a highpass filter in the reverb instrument 110. Note to self: learn to design better spatial processors.

The second zak technique I explored was implementing a gate. Every time an “Electro Bell” event occurs, the schedule opcode is used to instantiate an instr 90 event. instr 90 is basically an attack-sustain-decay envelope with razor thin sides. The gated delay processor, instr 120, responds to the gate by briefly capturing a segment of the drums, processing this audio chunk with filters and delay lines, and mixing the resulting effects back into the stereo zak channels.

The one last thing I played with was the macro system. Macros are a great thing. They dramatically reduced the difficulty of managing and adding zak channels. The one thing I’m disappointed about them is that macros defined in the orchestra aren’t recognized in the score and vice-versa. Perhaps there is a Csound way that I’m just not aware of. If not, no big deal, as I still have Perl to fall back onto.

I guess that’s it for now.

Visit: The Csound Blog