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.

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.

From the MUSIC IV PROGRAMMER’S MANUAL by M. V. Mathews and Joan E. Miller. (1967)

Utilizing the computer music language SuperCollider, Ballora translates data sets into audio. In this TEDxPSU talk, he discusses the potential role data sonification plays in understanding the natural world.

Did you know that WolframAlpha is also an FM Synthesizer?

Note: The “Play sound” button doesn’t always appear, but when it does it’s magical.

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.

fork{{play{SinOsc.ar(0.2*WhiteNoise.ar*1943+1932)*EnvGen.ar(Env.new([1,0.4,0],[0.05,2],-4),2,1,0,1,2)};15.wait}!inf} // 2:00 & Anniversary

fork{loop{play{f=_*3.pow(17.rand/13);e=EnvGen.ar(Env.perc,1,0.3,0,1,2);PMOsc.ar(f.([438,442]),f.(880),f.(e))*e};[1/6,1/3].choose.wait}}

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.

The Audio Programming Book, edited by Richard Boulanger and Victor Lazzarini, has a brand new Facebook page.

I personally love this book. I spent a lot of time with it when I first received my copy. Within that timeframe, many concepts of what is actually happening behind the scenes of digital audio and synthesis started to become clear to me.

Unfortunately, I got crazy busy, and had to shelf-it. Though I have plans to revisit it this upcoming October.

I did post some of the exercises I was working over at GitHub. If you’re interested:

MIDI to Frequency Chart
Breakpoint List
simple_aiff.c
simple_buffer.c
zero_shape.c