Category Archives: Csound

Introducing “Python Score” for Csound

Posted on by

PYTHON SCORE is a Python script for Csound score generation and processing. With it you will compose music easily and efficiently. No computer should be without one!

This effort has been weeks in the making, if you disregard the 10+ years I’ve spent creating various Csound score utilities I’ve coded up in Perl, Python, C and Java. Much of the focus on this project is directed at keeping the score familiar to Csounders, integrating Python with the Csound score using the CsScore bin feature, and removing as much unnecessary clutter. For example, you won’t need to open and close any files in your programs, Python Score handles it for you. And I’m attempting to keep the point of entry easy as possible for all; You’ll only need to know tiny bit of Python to get started.

Python Score is currently part of the Csound CSD Python library, though it will receive its own repository in the future. Here are the highlights. More information will follow.

The score() function

The first priority of Python Score is to allow traditional Csound score composers to transition into this new score environment in a near seamless fashion. Csounders will be able to use the full breadth of their knowledge of the traditional score they’ve acquired over the years. With the score() function, Csounders accomplish just that. The following example (test.csd) is a complete CsScore section in a Csound csd file:

<CsScore bin="python pysco.py">

score('''
f 1 0 8192 10 1
t 0 189

i 1 0 0.5 0.707 9.02
i 1 + .   .     8.07
i 1 + .   .     8.09
i 1 + .   .     8.11
i 1 + .   .     9.00
i 1 + .   .     8.09
i 1 + .   .     8.11
i 1 + .   .     8.07
''')

</CsScore>

A Csounder has successfully transitioned into this new environment once they’ve learned how to setup the call in the CsScore tag using the bin feature and embed their traditional Csound score code in a score() function. Once this has taken place, the composer is now only a step away from a plethora of new features to include in their arsenal of computer music tools.

The “cue” Object

Where as the score() function makes it easy for Csounders to make the leap into Python Score, the “cue” object is what makes it worthwhile. That and all the goodness Python brings to the mix.

The “cue” object enables composers to utilize nested programming techniques for placing events in time, similar to for-loops and if-then conditional branching. This allows composers to do things such as think-in-time localized to a measure rather than the absolute time of the global score.

The “cue” object works by translating the start values in pfield 2. Consider the following line of code:

score('i 1 0 4 0.707 8.00')

Looking at p-field 2, the event takes place at beat 0. By utilizing the “cue” object using the Python “with” statement, we can move the start time of the event without ever touching p-field 2. The follow block of code plays the same event at beat 64 in the score.

with cue(64):
    score('i 1 0 4 0.707 8.00')

The “cue” is a bit like a flux capacitor, as it makes time travel possible. Or at minimum, it saves a composer time, and lots of it, since they can easily move small and/or large sections of score, in time, without changing each and every value in the p-field 2 column. Notes, licks, phrases, bars, sections, entire compositions, etc… All of these time-based musical concepts benefit from the organizational power of the “cue”.

The following example from test10.csd shows the first three measures of Bach’s Invention 1. The beginning of each measure is designated by the use of a “with cue(t)” statement. Since the native time of the Csound score is in beats, and the fact that the piece is in 4/4, the values used with the “cue” object are multiples of 4.

with cue(0):
    score('''
    i 1 0.5 0.5 0.5 8.00
    i 1 +   .   .   8.02
    i 1 +   .   .   8.04
    i 1 +   .   .   8.05
    i 1 +   .   .   8.02
    i 1 +   .   .   8.04
    i 1 +   .   .   8.00
    ''')

with cue(4):
    score('''
    i 1 0 1    0.5 8.07
    i 1 + .    .   9.00
    i 1 + 0.25 .   8.11
    i 1 + 0.25 .   8.09
    i 1 + 0.5  .   8.11
    i 1 + .    .   9.00

    i 1 0.5 0.5 0.5 7.00
    i 1 +   .   .   7.02
    i 1 +   .   .   7.04
    i 1 +   .   .   7.05
    i 1 +   .   .   7.02
    i 1 +   .   .   7.04
    i 1 +   .   .   7.00
    ''')

with cue(8):
    score('''
    i 1 0 0.5 0.5 9.02
    i 1 + .   .   8.07
    i 1 + .   .   8.09
    i 1 + .   .   8.11
    i 1 + .   .   9.00
    i 1 + .   .   8.09
    i 1 + .   .   8.11
    i 1 + .   .   8.07

    i 1 0 1 0.5 7.07
    i 1 + . 0.5 6.07
    ''')

The “cue” also acts as a stack, meaning you can nest multiple “with cue(t)” statements. The following score event happens at 21.05. That is 16 + 4 + 1 + 0.05.

with cue(16):
    with cue(4):
        with cue(1):
            with cue(0.05):
                score('i 1 0 1 0.707 8.00')

P-field Converters

Csound is loaded with value converters. Though all of these exist in the orchestra side of Csound and there is currently no Csound mechanism to apply value converters to the score. Unless you count macros, but these are limiting. Two functions have been created to allow composers to apply pfield converters, either from an existing library or to create their own. These functions are p_callback() and pmap().

The p_callback() function registers a user-selected function that is applied to a selected pfield for a selected instrument. This registered function is applied when the score() function is called.

The pmap() function works similarly, except that it applies a user-selected function to everything already written to the score. Think of it is a post-score processor, while p_callback() is a pre-score processor.

The example (test2.csd) demonstrates two functions: conv_to_hz() which translates conventional notation into hz, and dB() which translates decibel values into standard amplitude values. Both of these are located in convert.py.

<CsScore bin="./pysco.py">

p_callback('i', 1, 5, conv_to_hz)

score('''
f 1 0 8192 10 1
t 0 120

i 1 0 0.5 -3 D5
i 1 + .   .  G4
i 1 + .   .  A4
i 1 + .   .  B4
i 1 + .   .  C5
i 1 + .   .  A4
i 1 + .   .  B4
i 1 + .   .  G5
''')

pmap('i', 1, 4, dB)

</CsScore>

What else?

The functions presented so far are just the basic mechanisms included in Python Score to help solve specific score related issues. Beyond these there is Python. Having a true mature scripting language at your disposal opens up score creation an processing in ways that Csound alone could never do on it’s own. What Python offers will be the topic of many follow up posts and examples to come.

For Ann (rising) by James Tenney

Posted on by

In 1969, American composer James Tenney wrote For Ann (rising), one of the “earliest applications of gestalt theory and cognitive science to music.” (source: wikipedia). The auditory illusion heard in the piece is achieved by layering multiple rising sine waves.

Tom Erbe recent wrote a blog post, Some notes on For Ann (rising), in which he describes in detail the specifications of the piece. This includes a thorough description, an excerpt of Csound code, and a PD patch he recently created. The PD patch is available for download at his site.

I myself love studying classic computer music languages and instrument designs, so this afforded me the perfect opportunity to study the piece. For Ann (rising) is also a personal favorite of mine.

First, I assembled the Csound version based on Erbe’s notes and Csound code excerpt, which was a straight forward process. I copied the instrument without any modifications. Then I generated the score with the following two lines of Python code:

for i in range(0, 240):
	print 'i 1 ' + str(i * 2.8) + ' 33.6'

The Csound csd is available for download here.

The next thing I did was realize the piece in SuperCollider based on Erbe’s Csound code. The technical simplicity of the instrument as well as the process for spawning voices allows for the piece to be expressed in less than 140 characters when translated into SuperCollider, making the following line of code twitter ready:

fork{{play{SinOsc.ar(EnvGen.ar(Env.new([40,10240],[33.6],\exp)),0,EnvGen.ar(Env.linen(8.4,16.8,8.4),1,0.1,0,1,2))!2};2.8.wait}!240}//JTenney

You can view the tweet here.

I want to thank Tom Erbe for publicly sharing his work and insight, which has allowed this classical computer music piece to be reconstructed in multiple modern day mediums.

Sampler Concrete

Posted on by


Photo by Carbon Arc. Licensed under Creative Commons.

First, I want to welcome aboard Jean-Luc Sinclair. As part of his NYU Software Synthesis class, he has graciously decided to share the articles he is writing for his students. His first contribution Organizing Sounds: Musique Concrete, Part I has already proven to be the most popular post here at CodeHop. Last year, before The Csound Blog became CodeHop, Jean-Luc had written another amazing piece, Organizing Sounds: Sonata Form, which I highly recommend. Thank you, Jean-Luc!

Now on to today’s example. (Get sampler_concrete.csd)

Many tape techniques are simplistic in nature and are easily mimic-able in the digital domain. After all, a sampler can be thought of as a high-tech featured-endowed tape machine. A more apt comparison would be that of a waveform editor such as Peak, WaveLab or Audacity.

I’ve designed a Csound instrument called “splice” that is about as basic as it gets when it comes to samplers. My hope is that the simplicity of the instrument will bring attention to the fact that many of the tape concrete techniques mentioned in Jean-Luc’s article are themselves simple.

Let’s take a look at the score interface to “splice”:

i "splice" start_time duration amplitude begin_splice end_splice

The start time and duration are both default parameters of a score instrument event. Three additional parameters are included for setting the amplitude, specifying the beginning time (in seconds) of the sample and specifying the end time (in seconds) of the sample to be played.

With this short list of instrument parameters, the following techniques are showcased in the Csound example: Splicing, Vari-speed, Reversal, “Tape” Loop, Layering, Delay and Comb Filtering.

Continuing Schaeffer’s tradition of using recordings of train, I’m using a found sound that I found on SoundCloud of the Manhattan subway. The recording is approximately 30 seconds in length. Most of the splicing in the examples take place between 17 and 26 seconds into the recording. Here are the results.

With this one simple instrument, it is entirely conceivable to compose a complete piece in the style of classic tape music.

SuperCollider Markov Chain

Posted on by

During my aggressive push to learn as much as possible about SuperCollider over the weekend, I’ve translated an earlier Csound etude of mine into SC code that generates a sequence in real-time using a Markov chain. I’ve come away with a few thoughts.

While I believe Csound definitely has an sharp edge in the DSP department, SuperCollider excels in allowing users to compose their own algorithmic sequencers. Even though the syntax of this Smalltalk-based language looks and feels very slippery to me, the SC code comes off as being much more concise and expressive than the Csound counterpart.

As for the work itself, I consider this to be very much a technical exercise; There is still so much about SuperCollider I’m completely ignorant of, including basic patterns and Pbinds, etc, and grinding against a problem like this is a big help in leveling up. Though it appears I’ll be able to build a generic Markov chain engine, separating the the SynthDefs from the nodes in a reusable function of some sort, which is the long term goal. This earliest of prototypes already goes pretty far in this direction, but there is plenty room for improvement.

Grab the SuperCollider code.

Faux Modem Audio

Posted on by

I’ve designed a series of audio samples based on classic modem technology and I’ve released them on SoundCloud under the Creative Commons attribution license.

Now for the extremely geeky party, how these samples are made. The sounds are generated with Csound using a form of frequency modulation called frequency-shift keying, a technique used by modems to transmit data to one another. Here’s a brief, and for this reason a not-to-entirely accurate, explanation of how a modem works. Modems communicate with each other by sending and receiving binary data between one another. The binary data is embedded into an audible signal by modulating a sine between two discreet frequencies at a specific time interval known as the baud rate.

To accomplish this modem-like sound, the randh opcode generates random noise at a user-specified frequency. The signal continues into the signal-to-binary converter, covered last week in Positive or Negative, creating a series of pulses consisting of 0s and 1s. These 0s and 1s are then mapped to the two desired frequency values by scaling then biasing them with the multiplication and addition opcodes. Finally, this signal is inserted into the frequency parameter of a sine wave oscillator, resulting in a sine wave whose frequency changes back and forth between two values at a timed interval determined by the randh at the top of the synthesizer graph.

Whether or not the results are authentic is kinda in the air, but isn’t necessarily the point. I’ve even played with parameters that have no basis in reality. The truth is, after the audible handshake a modem makes when connecting to another computer, I have no idea what the actual transmission sounds like and couldn’t find a reliable recording online. Based on what I’ve read, my design isn’t accurate, but close enough for sound design purposes. However, I’m thinking that designing a virtual modem simulator could be fun. Might have to pencil this project in for October.

Get the clean block diagram.

Get faux_modem.csd.

Positive or Negative

Posted on by

I recently ran into a situation in Csound in which I needed to know if a signal was positive or negative, and it had to work at the audio rate. I could have used if-else conditional statements, though these only work at k-rate, and would have required implementing a User-Defined Opcode utilizing the setksmps opcode. Perhaps I was lazy at the time, or in the mood for some simple hacking fun, but I decided to forgo this obvious solution for something else. And I wanted to do it without using conditionals.

Get positive_or_negative.csd.

The first thing I tried was using the > (greater than) opcode. In some other languages, an expression such as (0.8 > 0) will return a value of 1, while a (-0.8 > 0) will yield a 0. Unfortunately, this opcode is not designed this way in Csound. So I kept looking.

I eventually came up with a two opcode solution utilizing limit and ceil(). First, the signal passes through the limiter, clipping the waveform between the value range of 0.0 and 1.0. As the signal continues through the ceil opcode, any non-zero value becomes a 1.0, while a zero value remains 0.0.

For example, processing a sine wave through this configuration creates a unipolar square wave.

Now what? That’ll have to wait for another post.

Csound Group at SoundCloud

Posted on by

The Csound Group at SoundCloud is a collection of user submitted tracks that are created with the Csound computer music language.

At the time of posting this, there are 39 tracks listed. I’d like to see this number grow. So if you have anything of interest, whether it be a composition, improvisation, or patch, do add it to the group. Providing it’s built with Csound, of course.

Tempo-Synced LFO Wobble Bass

Posted on by

There is a simple, but highly useful hack I discovered a few years ago in which it’s possible to pass the current tempo from the score to an instrument using p3. And since dubstep is all the rage these days, I’ve designed a practical example in which a tempo-synced LFO modulates the cutoff of a low pass filter to create that “wobbly” bass effect.

Download the code here.

Passing the tempo of the score to an instrument is a fairly straight forward process. First, always set p3 to 1; This value of 1 is translated into seconds-per-beat (SPB) when the score is preprocessed. Second, use p4 for the desired duration. Third, in the instrument code, the following two lines obtain the tempo in SPB from p3 and then resets the duration of the instrument to the desired length:

ispb = p3 ; Seconds-per-beat. Must specify "1" in score
p3 = ispb * p4 ; Reset the duration

Now that we have the tempo, we can create a low frequeny oscillator that is synced to the tempo. To create that dubsteb wobble effect, p7 is designated as the division of the note. We need to take this p7 value and translate it into Hz utilizing the SPB value:

idivision = 1 / (p7 * ispb) ; Division of Wobble

Plugging this value in the frequency parameter of an oscillator yields a tempo-synced LFO. (some drift may occur over long periods of time)

klfo oscil 1, idivision, itable

Try changing the tempo in the score, and you’ll notice that the wobbles stay consistent relative to the tempo.

Csound Inspired Art by Michael Orr

Posted on by

By Michael Orr
Artist’s Website

Here is Michael’s profile from his August Art Opening:

“Just a few years before Michael Ladd Orr was born, Alvin Toffler introduced the concept of “future shock”. The concept, and the book of the same name, proposed we were entering an age when the future was arriving “prematurely” – when one could stay in one place and the culture around him/her would change so rapidly that it would have the same disorienting effect as simply moving to a foreign culture – when the rate of technological advancement would increase exponentially until the average person simply wouldn’t be able to keep up. Orr’s work often hints at these notions, whether he intends this or not is up for discussion. His art studio and tools are completely mobile at all times so he can create on the spot and in the moment. He may post a newly created image on the web or drop it in the mail. There is no time to dictate meaning, only to reinterpret the numerous images and impressions as they go whizzing by. Consumerist culture’s infinite supply of marketing images collides with arbitrary hand-drawn patterns. Ordinarily warm and vibrant yellows and oranges become jarring against nonsensical shapes and random household items. There is the sense of an artist trying to inject a touch of restraint and familiarity into a machine that is insatiable and alien. Collage becomes collision, but all the while a childlike kind of wonder and playfulness seeks to burst through the surface. Orr, 35, was born and raised in and around Atlanta, where he continues to live, work, and ply his craft.”

Event_i

Posted on by

The event opcodes are some of my favorites in all of Csound. They are highly versatile in their application, as they can be used for algorithmically generating notes, transforming scores events, creating multiple interfaces to a single instrument, for triggering grains in a granular patch, etc. The list goes on and on.

Today’s example uses the event_i opcode to generate multiple score events from a single score event. The basic run down is this: Each instr 1 event generates 5 events for instr 2. Each of these 5 events are staggered in time, with the delay between notes set by the idelay parameter. The pitches also have a fixed half-step sequence of [0, 3, 7, 5, 10] in relation to the base pitch specified in the ipch parameter. Take a listen.

Download event_i.csd

Here are a couple of exercises to help get you going:

Exercise: 1

Create a new note pattern sequence. The last parameter of event_i is used to set the relative pitch. Set the value for x in ‘ipch * 2 ^ (x / 12)’.

Exercise: 2

Alter the rhythm. The third parameter controls how far into the future a particular event is trigger. The example uses integers, though using floats such 1.5 and 3.25 can completely transform the characteristics of the output.

Exercise: 3

Write a short etude with your modified instrument.