Archive for December, 2006

Back in the ADSR

Wednesday, December 27th, 2006

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

BassOnde

Saturday, December 23rd, 2006

“Experimental Ambient Video”

Posted to youtube by HplanKjp.

An Experiment in Csound Blogging

Friday, December 22nd, 2006

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

j E d i t

Tuesday, December 19th, 2006

Wars have been started over text editors. Flame wars. The most famous example being Emacs vs. Vi. Those people can have their war if they want it. I, myself, prefer jEdit.

I’m back, ahhhh yeaaaah!

Wednesday, December 13th, 2006

I’ve found myself busy with a few additional projects that have been eating my time, thus no blogging. I have no issues about pushing this blog aside for weeks, or perhaps months at a time. However, I do feel it is time to re-commit myself to this place. I love doing it. Perhaps I just bit off too much for those first couple of months. I was so wrapped up in the fantasy of having the world’s most popular blog, that I over did it and burnt out. Now that’s out of my system, I’m much more comfortable taking my time and writing what I should be writing about: all the weird shit that goes through my head.

While I was MIA, I rediscovered both Perl and Csound. Also wrote part one of a two part article for the Csound Journal titled “Perl and Csound.” It’ll be out, soon. I’ve already started part two, and having a wonderful time writing it. Part one is more or less a primer, part two is where the magic happens. The one concern I have is that I’m going to find it difficult to narrow my examples down while still covering a massive amount of useful info. The best part of this hole experience is that I’m learning so much writing this. My thought processes have completely switched into Csound mode, and my mind is open to new possibilities. So I guess this is what enlightenment feels like. I’d best bottle it up before my feet touch the ground.