The Backlog

I’m reposting all the Csound Blog posts from the original site.  The write-ups are stored within the Csound files themselves.  I’m really looking forward to posting new content, and will hopefully have something up by the end of the week.  Without further ado:

Tom Wiltshire’s Electric Druid Synth DIY pages

Electric Druid Synth DIY pages.

“I’ve finally got around to something that has been a dream for a long while – building my own synthesizer… So far, I’ve managed to write firmware for two devices, a voltage-controlled LFO and a voltage-controlled ADSR envelope generator, modelled on the CEM 3312 and SSM2056.”

I have a love/hate relationship with sites like these. On one hand, the material is fascinating, and I gain a lot of insight on various ways to approach instrument design in Csound. On the other hand, I sooo wish I had the time to hone my soldering iron skills and learn to program for a microcontroller. There must be something entirely satisfying with the hands on approach.

Link via Matrixsynth.

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