Listen: mp3

Download: splice_and_stutter.csd, BT Sample Pack (13.2 MB)

Here’s a brief rundown of today’s example. A drum loop is loaded into an f-table with the instrument LoadSample. The instrument SampleEngine plays back selective parts of the loop. Instruments Basic, Stutter and Random are interface instruments that simplify the process of triggering samples.

The LoadSample instrument loads a sample into an f-table, while storing information about the sample into an ad hoc data structure created from chn busses. Here isn’t the place to go into detail. I will say that it is akin to a C struct, and stores the file name, sample rate, length of file (in samples), the tempo, and the number of beats (quarter notes) in the loop. All the user-defined opcodes are support opcodes for the data structure.

SampleEngine is the heart of this piece. It works by triggering discreet notes from within the loop, with the loop offset being determined by input it receives via p-field 7. The offset unit is in beats. Let’s say the loop is 16 beats long. A passed value of 0 plays the first quarter note. A value of 1 plays the second quarter note of the loop, etc.

This instrument is designed to be played by other instruments, rather than being triggered directly by a score i-event. That is…

Instead of having multiple samplers that do various things, I created a single complex sampler engine that is capable of a wider range of tricks. The problem with complex instruments in Csound is that writing score events can be cumbersome to write and certainly hard to read, especially when dealing with several parameters. This is where the interface instruments come into play.

The interface instruments Basic, Stutter and Random help us tame the complexity of SampleEngine by reducing the number of p-fields needed by the score, and by defining clear behaviors.  Basic is a no thrills controller that simply triggers part of the loop. Stutter, well, stutters. Random randomly picks a beat and plays it.

A greatly added benefit to this approach is that the score is much easier to read. Instead of trying to figure out if a particular i-event stutters or not by scanning a row of numbers, one can just casually look at the name of the instrument used. To put it another way, does this stutter?

i 5 7 1 0.25 0.5 100 12 0.083 1 0

How about this?

i $Stutter 7 1 0.25 0.5 100 12 [1 / 12]

There are a lots of ins and outs to today’s example. And I admit, I skipped over most of them. If there is a particular issue or issues you wish for me to expand on, comment below, and I’ll make it a priority to blog about it in the future.

This sampler is a derivitive work based on an instrument co-developed by Jean-Luc Sinclair (aka Jean-Luc Cohen) and myself back in 2006. The loop in today’s example is by BT (aka Brian Transeau), released under a Creative Commons attribution license, and released as part of the OLPC Sample Library. You can obtain this sample and others here. (13.2 MB) You will need the loop “105 Blanketed Lama.wav” in order to run the csd file.

Update: There is an issue with the CSD file not running on Windows Windows Me (or earlier). There is now a fix. Download the new splice_and_stutter.csd, and see line 269 for details. This only applies to users of Windows Windows Me (or earlier versions).

Thanks to everyone on the Csound Mailing List who helped straighten this out.

I had to read the Music V manual, but I finally found the bit-depth used for the examples in Mathews’ The Technology of Computer.  12-bit, just as I suspected. According the manual, the digital-analog-converters (DAC) at Bell Telephone Laboratories (BTL) operated with 12-bit samples. (pg. 168)

I don’t recall running across a 12-bit audio-file, ever. They just don’t make them like they used.  I don’t even think Csound natively supports outputting a 12-bit file. However, it does allow us to easily simulate it with the 0dbfs opcode.

I rewrote part the CSD file from part 1 to better preserve the the original structure of the Music V example. Instead of rescaling the audio output signal of instr 1 by a factor of 16, I elminated this multiplier, and set the global dynamic range to 12-bit with 0dbfs = 2048. Original Music V amplitudes can now be used without modyifing the values or making unnecessaring changes to instrument translations. Here is the new CSD: Csound_Vs_MusicV_pt2.csd

Csound makes changing the dynamic range easy. In fact, almost all modern software allows users to choose from a list of several bit depths. Music V, not so much. When Music V was installed at a new installation, parts of the program would have to be coded, in assembly and/or Fortran, specifically for that particular system. Including the dynamic range. In theory, other computer facilities might have used a different dynamic range other than 12-bit, based on the hardware they had on site.

One interesting bit of information I discovered is something that could be considered a precursor to the modern audio buffer.

The General Electric GE645 computer at BTL used a 36-bit word length machine. In BTL’s particular setup, Music V would have to create 3 samples and collect them into a single 36-bit word before sending this word to the digital reel-to-reel. This isn’t too unlike the latency buffer found in programs such as Ableton Live, Max, Reaktor, etc., where n amount of samples are collected into a temporary buffer before sending the buffer to the DAC.

Csound is a direct descendant of the Music-N series of computer music languages developed by Max V. Mathews.  One could make the case that all digital synthesizers are descendants, or at least distant cousins, of Music-N.  Comparing and contrasting Csound with Music V, the similarities are glaringly obvious.

I own a copy of the 1981 edition of Max Mathews’ The Technology of Computer Music. The original was released in 1969 — that’s 40 years ago.  I’ve read it cover to cover.  I’ve translated some of the examples to Csound.  Much of the knowledge contained in that little red hardcover book is still relevant today.

I thought it would be fun to compare and contrast the two languages.  Here is The Simplest Orchestra example from pages 44-46:

1	INS 0 1 ;
2	OSC P5 P6 B2 F2 P30 ;
3	OUT B2 B1 ;
4	END ;
5	GEN 0 1 2 0 0 .999 50 .999 205 -.999 306 -.999 461 0 511 ;
6	NOT 0 1 .50 125 8.45 ;
7	NOT .75 1 .17 250 8.45 ;
8	NOT 1.00 1 .50 500 8.45 ;
9	NOT 1.75 1 .17 1000 8.93 ;
10	NOT 2.00 1 .95 2000 10.04 ;
11	NOT 3.00 1 .95 1000 8.45 ;
12	NOT 4.00 1 .50 500 8.93 ;
13	NOT 4.75 1 .17 500 8.93 ;
14	NOT 5.00 1 .50 700 8.93 ;
15	NOT 5.75 1 .17 1000 13.39 ;
16	NOT 6.00 1 1.95 2000 12.65 ;
17	TER 8.00 ;

A loose translation into Csound looks something like this:

<CsoundSynthesizer>
<CsInstruments>
sr     = 44100
kr     = 44100
ksmps  = 1
nchnls = 1

instr 1	
	a2 oscil p4, cpspch(p5), 2
	out a2 * 16
endin
</CsInstruments>
<CsScore>
f2 0 512 -7 0 50 0.999 155 0.999 101 -0.999 155 -0.999 50 0

i 1 0    0.50  125 8.04
i 1 0.75 0.17  250 8.04
i 1 1.00 0.50  500 8.04
i 1 1.75 0.17 1000 8.05
i 1 2.00 0.95 2000 8.07
i 1 3.00 0.95 1000 8.04
i 1 4.00 0.50  500 8.05
i 1 4.75 0.17  500 8.05
i 1 5.00 0.50  700 8.05
i 1 5.75 0.17 1000 9.00
i 1 6.00 1.95 2000 8.11
e 8
</CsScore>
</CsoundSynthesizer>

I’ll spend the next few blogs breaking down these examples, discussing the many differences and similarities, in hopes that we can learn something about our digital synthesis roots.  In the meantime, you can download this Csound file to listen for yourself: Csound_Vs_MusicV_pt1.csd