Category Archives: the cosmos

everything that is && everything that isn’t

Robot Voices and Android Grooves

Posted on by

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

Visit:
The Csound Blog

Csound Journal Issue 5

Posted on by

The 5th issue of the Csound Journal has been published at cSounds.com. A range of topics are discussed, including Pure Data, an art installation, HPKComposer and Perl. To quote editor Stever Yi, “It never ceases to amaze me the number of different ways that people are using Csound and the wide variety of musics being made.” [source]

I previously mentioned I had written an article for the journal. I’m happy to announce that “Perl and Csound – Part I” is included in this issue. I want to personally thank the editors James Hearon and Steven Yi for giving me the opportunity to contribute to one of my favorite online publications.

TamTam, Csound and the OLPC

Posted on by

Just last week, a friend of mine was telling me that Csound is included in the One Laptop Per Child program (OLPC.)

Last night, I coincidentally stumbled across the development blog for TamTam, “a suite of three applications / activities developed for the $100 laptop.” [source]  The program is implemented using Python and PyGTK, and utilizes Csound as its synthesis engine.  The TamTam GUI appears to be very user-friendly, and reminds me of a simplified version of Max/MSP combined with a midi sequencer.  

The OLCP is, among other things, a musical instrument.  The fact that this musical instrument is going to make its way into the hands of children spanning dozens of cultures fascinates me to no end.

As a side note, I can’t help but think of the NAVI computer in Serial Experiments Lain.  I look forward to the day OLPC laptops become commercially available, so that I may get my hands on one.

Back in the ADSR

Posted on by

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