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