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

A Micro Intro to Macros

The Csound Blog
Issue #7

“I’m continuing with what I started in the last blog ‘Adding Zak to the Mix.’ As promised, I’m breaking down the zak mixer into its respective modular components, beginning with Csound macros.”

Topics covered:

  • Macros
  • #define
  • #include

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

Adding Zak to the Mix

The Csound Blog
Issue #6

“It has been too long since the last Csound Blog. This is why I’m personally excited to announce this newest edition, ‘Adding Zak to the Mix.’

Today’s topic is how to model a studio mixer in Csound using Robin Whittle’s zak opcodes.[1] I will actually be stretching this subject over an unspecified number of blog entries, as I couldn’t possibly cover every significant nuance in one write-up. What I’m presenting here today is merely an overview, while in the following issues I will break down everything into its respective modular components. Not only will I cover the design of this zak mixer, I will present new ways in which you can organize your orchestras, along with how to unlock the potential of your patches using control instruments.”

Topics covered:

  • Zak
  • Model of a Studio Mixer
  • Macros
  • Signal Routing
  • Organization

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

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 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