Splice and Stutter

Posted on by

Splice and StutterToday on The Csound Blog, we’re going to learn how to build a loop-based sampler out of common household ingredients.

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.

Csound Vs. Music V — FIGHT! Pt. 4

Posted on by

The Technology of Computer Music Mathews

Let’s look again at the code presented on page 45 of The Technology of Computer Music:

INS 0 1 ;
OSC P5 P6 B2 F2 P30 ;
OUT B2 B1 ;
END ;
GEN 0 1 2 0 0 .999 50 .999 205 -.999 306 -.999 461 0 511 ;
NOT 0 1 .50 125 8.45 ;
NOT .75 1 .17 250 8.45 ;
NOT 1.00 1 .50 500 8.45 ;
NOT 1.75 1 .17 1000 8.93 ;
NOT 2.00 1 .95 2000 10.04 ;
NOT 3.00 1 .95 1000 8.45 ;
NOT 4.00 1 .50 500 8.93 ;
NOT 4.75 1 .17 500 8.93 ;
NOT 5.00 1 .50 700 8.93 ;
NOT 5.75 1 .17 1000 13.39 ;
NOT 6.00 1 1.95 2000 12.65 ;
TER 8.00 ;

The following list compares Music V mneumonics to their Csound opcode equivalents in the order in which they appear the previous example:

INS => instr
OSC => oscil
OUT => out
END => endin
GEN => f
NOT => i
TER => e

A Music V instrument definition begins with INS and and is terminated with END. This is nearly identical to Csound’s instr and endin. Music V does allow one capability that Csound lacks, as instrument defininitions in Music V have a parameter that lets users specify the time in which they come into being. Hopefully someday, Csound will include a more mature version of this feature, where users can dynamically create and destroy instruments in the middle of a score or performance. *crosses fingers*

Though OSC and oscil are similar, there are some noticeable differences in their implementations. In part 3, I mentioned that Csound supports control signals, and Music V does not. The oscil opcode is an example of a unit generator that can output both audio rate and control rate signals.

Both support a simple amplitude value, but diverge on frequency. Instead of a frequency paramenter, Music V has an increment parameter that determines the frequency of the unit generator. The increment parameter is used to specify the number of samples that are sequentially skipped in a stored function for each pass. The following equation is used to convert increment values to frequencies (Mathews, pg. 127):

frequency = sampling rate * increment / (function length in samples - 1)

The first note played in the example specifies an increment value of 8.45. Let’s do the math:

330.72407045009783 = 20000 * 8.45 / (512 - 1)

An increment value of 8.45 translates to roughly 330Hz.  Provided that the sampling rate is 20kHz and the table size is 512.

The problem with Music V’s method is that any changes made to the size of the stored function table or the sampling rate greatly affects the frequencies of the oscillators. The reason why I modified my copy of Music V is because the examples in the book were designed to render with a sampling rate of 20kHz, not 44.1kHz. Thus, frequencies were higher than they were supposed to be, and the LFOs were right out.

This is where Csound is much more user-friendly as users specify a frequency, and all the increment calculations are done automatically, making life a little easier for us Csounders.

Thanks for reading this first Csound Blog mini series. Hopefully you’ll stay tuned.  A lot of great topics are coming up, including coding techniques, composition, sound design, etc..

Let’s look again at the code presented on page 45 of The Technology of Computer Music:
INS 0 1 ;
OSC P5 P6 B2 F2 P30 ;
OUT B2 B1 ;
END ;
GEN 0 1 2 0 0 .999 50 .999 205 -.999 306 -.999 461 0 511 ;
NOT 0 1 .50 125 8.45 ;
NOT .75 1 .17 250 8.45 ;
NOT 1.00 1 .50 500 8.45 ;
NOT 1.75 1 .17 1000 8.93 ;
NOT 2.00 1 .95 2000 10.04 ;
NOT 3.00 1 .95 1000 8.45 ;
NOT 4.00 1 .50 500 8.93 ;
NOT 4.75 1 .17 500 8.93 ;
NOT 5.00 1 .50 700 8.93 ;
NOT 5.75 1 .17 1000 13.39 ;
NOT 6.00 1 1.95 2000 12.65 ;
TER 8.00 ;
The following list compares Music V mneumonics to their Csound opcode equivalents in the order in which they appear the previous example:
INS => instr
OSC => oscil
OUT => out
END => endin
GEN => f
NOT => i
TER => e
A Music V instrument defintion begins with INS and and is terminated with END. This is nearly identical to Csound’s instr and endin. Music V does allow one capability that Csound lacks, as instrument defininitions in Music V have a parameter that lets users specify the time in which they come into being. Hopefully someday, Csound will include a more mature version of this feature, where users can dynamically create and destroy instruments in the middle of a score or performance. *crosses fingers*
Though OSC and oscil are very similar, there are some noticeable differences in their implementations. Yesterday, I mentioned that Csound supports control signals, and Music V does not. The oscil opcode is an example of a unit generator that can output both audio rate and control rate signals.
Both support a simple amplitude value, but diverge on frequency. Instead of a frequency paramenter, Music V has an increment parameter that determines the frequency of the unit generator. The increment parameter is used to specify the number of samples that are sequentially skipped in a stored function for each pass. The following equation is used to convert increment values to frequencies (Mathews, pg. 127):
frequency = sampling rate * increment / (function length in samples – 1)
The first note played in the example specifies an increment value of 8.45. Let’s do the math:
330.72407045009783 = 20000 * 8.45 / (512 – 1)
An increment value of 8.45 translates to roughly 330Hz.  Provided that the sampling rate is 20kHz and the table size is 512.
The problem with Music V’s method is that any changes made to the size of the stored function table or the sampling rate greatly affects the frequencies of the oscillators. The reason why I modified my copy of Music V is because the examples in the book were designed to render with a sampling rate of 20kHz, not 44.1kHz. Thus, frequencies were higher than they were supposed to be, and the LFOs were right out.
This is where Csound is much more user-friendly as users specify a frequency, and all the increment calculations are done automatically, making life a little easier for us Csounders.
Thanks for reading this first Csound Blog mini series. Hopefully you’ll stay tuned.  A lot of great topics are coming up, including coding techniques, composition, sound design, etc.

Csound Vs. Music V — FIGHT! Pt. 3

Posted on by
Thanks to Dr. Victor Lazzarini, I now have a working copy of Music V in my possession. I’ve been tinkering with it all weekend to try and get a better understanding of the system, temporarily frying my brain in the process. All in all, it’s been great experience so far.
Sampling Rate. Just as I had mentioned in part 2 that the bit depth of the dynamic range was installation specific, the sampling rate of Music V also depended greatly on the hardware on hand.
In Csound, the sampling rate is determined in the header of the orchestra, and can be overridden with a command-line flag. In Music V, the sampling rate is hard-wired into the Fortran code.
The version of Music V that was sent to me uses 44.1kHz. I created a modified version to run at 20kHz to coincide with sampling rate specified in The Technology of Computer Music. (Mathews, pg. 43) Had to get my hands a little dirty with the Fortran code, though the procedure turned out to be easier than expected — just replaced all instances of 44100 with 20000.
Sampling rate alone doesn’t paint the full picture, as there is also the control rate to consider. Csound fully supports control rates, signals of a usually lower sampling rate used to control / modulate other unit-generators.
Back in the day when computers were *really* slow, and real-time performable digital synths were more fantasy than reality, rendering a short piece of music could take hours. To help reduce this time, control signals were introduced to greatly reduce the number of required computations.
Even today, using a secondary lower sampling rate to control aspects of a digital synth engine or DSP is standard practice. In live situations, a control rate allows musicians to run more effects and instruments than would be possible if everything was computed at the audio rate.  So there is great reason why software like Reaktor fully embraces this older, yet highly effective concept.
In the Csound manual, Berry Vercoe describes how control rates came to be in Csound: “With Music 11 (1973) I took a different tack: the two distinct networks of control and audio signal processing stemmed from my intensive involvement in the preceding years in hardware synthesizer concepts and design. This division has been retained in Csound.”
Unfortunately for Music V, there is no such thing as a control Thanks to Dr. Victor Lazzarini, I now have a working copy of Music V in my possession. I’ve been tinkering with it all weekend to try and get a better understanding of the system, temporarily frying my brain in the process. All in all, it’s been great experience so far.

The Technology of Computer Music MathewsThanks to Dr. Victor Lazzarini, I now have a working copy of Music V in my possession. I tinkered with it all weekend to get a better understanding of the system, temporarily frying my brain in the process.

Sampling Rate. Just as I had mentioned in part 2 that the bit depth of the dynamic range was installation specific, the sampling rate of Music V also depended greatly on the hardware on hand.

In Csound, the sampling rate is determined in the header of the orchestra, and can be overridden with a command-line flag. In Music V, the sampling rate is hard-wired into the Fortran code.

The version of Music V provided to me uses a rate of 44.1kHz. I created a modified version to run at 20kHz to coincide with sampling rate specified in The Technology of Computer Music. (Mathews, pg. 43) Had to get my hands a little dirty with the Fortran code, though the procedure turned out to be easier than expected — just replaced all instances of 44100 with 20000.

Sampling rate alone doesn’t paint the full picture, as there is also the control rate to consider. Csound fully supports control rates, signals of a usually lower sampling rate used to control / modulate other unit-generators.

Back in the day when computers were *really* slow, and real-time performable digital synths were more fantasy than reality, rendering a short piece of music could take hours. To help reduce this time, control signals were introduced to greatly reduce the number of required computations.

Today, using a secondary lower sampling rate to control aspects of a digital synth engine or DSP is standard practice. In live situations, control rates allow musicians to run more effects and instruments at any given time than would be possible if everything was computed at the audio rate.  So there is great reason why software like Reaktor fully embraces this older, yet highly effective concept.

Unfortunately for Music V, there is no such thing as a control rate.

In the preface of Csound manual, Barry Vercoe briefly describes how control rates came to be in Csound:

With Music 11 (1973) I took a different tack: the two distinct networks of control and audio signal processing stemmed from my intensive involvement in the preceding years in hardware synthesizer concepts and design. This division has been retained in Csound.

Csound Vs. Music V — FIGHT! Pt. 2

Posted on by

The Technology of Computer MusicFirst, I want to make it clear that I’m making many assumptions about Music V that are likely wrong. I have a mixed bag of fossilized Music V bones, and I’m doing my best Emily Deschanel impression to reconstruct them. If you are knowledgable of such things and catch an error, or would like to expand, please post a comment. With that said…

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 Vs. Music V — FIGHT! Pt. 1

Posted on by

The Technology of Computer Music Mathews

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

The Backlog

Posted on by

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: