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.

Organizing Sounds: Musique Concrete, Part I

Posted on by

 

I.               Musique Concrete and the emergence of electronic music

Musique Concrete is nothing new. It was pioneered by Pierre Schaeffer and his team in the early 1940’s at the Studio d’Essai de la Radiodiffusion Nationale, an experimental studio created initially to serve as a resistance hub for radio broadcasters in occupied France, in Paris. While Musique Concrete might not be anything new today, at the time however, it represented a major departure from the traditional musical paradigms. By relying entirely on recorded sounds (hence the name “concrete”, as in ‘real’) as a means of musical creation, Schaeffer opened the door to an entirely new way of not only making, but also thinking music. It represented a major push towards a number of new directions.

Timbre was all of a sudden an equally important musical dimension as pitch had been up until then, something that composers like Edgard Varese had long been thinking and writing about. It also paved the way for the emergence of new compositional forms and strucutures. As Pierre Boulez pointed out in “Penser la musique aujourd’hui”, musical structures were traditionally perceived by the listener as a product of the melody. By removing the melody altogether, and working instead with sound objects, Schaeffer became a bit of an iconoclast. As he himself pointed out in his “Traité des objects musicaux”, the composer is never really free. The choice of his or her notes is based upon the musical code that he himself and his audience have in common. When Musique Concrete was invented, the composer had moved one step ahead of his audience, and was, to some extent, liberated.

One of the earliest pieces of the genre, and perhaps the most famous to this day is Schaeffer’s own “étude aux chemins de fer”, where the composer mixed a number of sounds recorded from railroads such as engines, whistles and others, in order to create a unique, and truly original composition.

You can listen to the piece here: http://www.synthtopia.com/content/2009/11/28/pierre-schaeffer-etude-aux-chemins-de-fer/

By today’s standards, the techniques used by the pioneer of the genre were rudimentary at best, yet they were, and remain, crucial tools of electronic music creation to this day. By taking a look at these techniques, and applying them to a computer music language such as Csound, we can not only gain a better understanding of this pivotal moment in music history, but also deepen our knowledge of sound and composition.

II.            Concrete Techniques

The early composers of Musique Concrete mostly worked with records, tape decks, tone generators, mixers, reverbs and delays. Compared to the tools available to the computer musician today, it’s a rather limited palette indeed. This however forced the composer to be much more careful in the selection of the source materials, mostly recordings of course, and far more judicious with the use of the processes to be applied. Using recordings as the main source of sounds confronts the composers with decisions early on in the compositional process, which will have profound consequences on the final piece.

1.     Material Selection

While perhaps a bit reductive, the compositional process could be thought of as the selection and combination of various materials. When working with sound objects, the selection process is maybe even more crucial.

It could easily be argued that this process begins at the recording stage. If you happen to be recording your own material, the auditory perspective you chose will have a profound impact on the outcome of the sound. As Jean-Claude Risset pointed out in the analysis of his 1985 piece “Sud”, the placement and choice of the microphone will hugely change the sound itself. For instance, placing the microphone very close to the source will have a magnifying effect on the sound, while moving it back a bit will give a broader view of the context within the sound is recorded, allowing more ambient sounds and atmospheres to seep in. This is something audio engineers have been very aware of for a long time, but that often gets overlooked by computer musicians. I’m quite fond of small microphones, such as Lavalier mics for instance, which allow the engineer to place them in places where a traditional microphone will not fit, very close to the sound source. This makes for some very interesting results. For instance, a lav mic placed right below a rotating fan will make it sound like a giant machine, shaking and rattling as if it were 60 feet tall inside a giant wind tunnel. As always, experimentation and careful listening is key.

If you are working with already recorded material, an interesting approach is to work with different sounds, but that evoke similar emotions. This approach was favored by the American composer Tod Dockstader, who in his 1963 piece “Apocalypse” used a recording of Gregorian chant as a vocalization to the slowed down sound of a creaky door opening and closing.  Dockstader came from a post-production background, and perhaps it is no accident that Schaeffer had a background in broadcasting and engineering as well.

You can listen to an excerpt of Apocalypse here: http://www.youtube.com/watch?v=TYabnQctxpo

This technique, of using very different sounds that evoke similar or complementary emotions, is also often used by film sound designers.

Star Wars’ sound designer Ben Burtt often speaks of this in his process. By working with familiar sounds, combining them in unexpected ways and putting them to picture, he has been able to create some of the most successful and iconic sounds in the history of film.

2.    Sound techniques and manipulations

While the technology available to the pioneers of musique concrete was fairly primitive, composers managed to come up with a number of creative methods for sound manipulation and creation. A non exhaustive but comprehensive list of these would include:

–       Vari-speed: changing the speed of the tape to change the pitch of the sound.

–       Reversal: playing the tape backwards

–       Comb Filtering: by playing a sound against a slightly delayed version of itself various resonant frequencies are brought in or out.

–       Tape loops: in order to create loops, and grooves out of otherwise non rhythmic material, composers would repeat certain portions of a recording.

–       Splicing: to change the order of the material, or insert new sounds within a recording

–       Filtering: to bring in or out different frequencies of a sound and change its quality and texture

–       Layering: Either done by recording multiple sources down to a new reel or by mixing them in real time via a mixing board.

–       Reverberation, delay: used to create a sense of unity, or fusion between sound sources coming from different origins, and a great way of superimposing a new sense of space on an existing recording.

–       Expanded-compressed time: by slowing down, or speeding up then reversing the direction of a sound.

–       Panning: allowing the composer to place the sound within a stereo or multichannel environment

–       Analog Synthesis: Although the genre was based on recorded sounds mostly, composers sometimes inserted tones and sweeps from oscillators in their compositions.

–       Amplitude modulation: Often done by periodically varying the amplitude of a sound or applying a different amplitude envelope over it.

–       Frequency Modulation: Although frequency modulation as a synthesis technique was discovered long after the beginnings of tape music, vibrato was a well-known technique long before then.

In the next installment of this article, we will look at practical ways to apply these techniques to Csound, and create our own musique conrete etude. In the meantime I encourage you to listen to more music by the composers mentioned above, and as always, experiment, experiment, experiment.


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.