At the Sounding Edge: What's Going On with Csound?
On April 19, I will board a flight to Germany, where I will be attending the 3rd annual conference on Linux audio. The conference will be held in the lovely city of Karlsruhe at the amazing ZKM, the Zentrum fur Kunst und Medientechnologie (Center for Art and Media Technology). I'm excited about this conference, especially because the last two were so successful in their short- and long-term effects. It's a wonderful opportunity to meet and chat with the leading lights of the Linux audio software world, so if you're in the area, stop by ZKM and check out the festivities. I've included a URL for the conference details at the end of this article; check it out to see what the schedule holds. As you can tell from the topics list, it's going to be another great event.
This year's conference includes at least two presentations on Csound. I'm pleased about this, because Csound is one of the best and longest-developed software sound synthesis (SWSS) languages. A few years ago, members of the Csound community successfully lobbied to revise its original licensing terms to bring it into the truly free and open-source fold, and recent development efforts appear to have vindicated that decision. This article presents a brief look at what's going on in the latest development branch of Csound, known to its programmers and users as Csound5.
Csound has been in development since the 1970s, predating personal computers. As might be expected, its codebase has become a bit dusty, particularly regarding modern programming techniques. Csound's ease of extensibility has promoted a great broadening of its processing powers, but at the lower levels, the code currently is undergoing a complete revision. Almost every aspect of the original source tree has come under new scrutiny that should result in a faster, more efficient Csound.
Incidentally, there are two parallel development tracks for Csound, one for a version that retains much of the classic Csound codebase (Csound4) and another that incorporates extensive and profound changes to the code (Csound5). The tracks are trying to stay in sync with each other, with the understanding that Csound5 will become the eventual successor to the earlier code.
Csound5 introduces much more than a mere reorganization of sources. Modularization has been pursued with a vengeance, many changes have been made at the code level and many new features have been introduced. The code-level changes include improvements such as a wholesale removal of static and global variables and the introduction of a new build procedure--the GNU autotools have been replaced by the SCons system. The focus of this article, however, is the user level, so let's look at what new goodness Csound5 brings to us.
Csound5 for Linux currently is available only in CVS sources. Complete instructions for retrieving, compiling and installing Csound5 are included with the Csound manual (see Resources) so I am not going to repeat them here. However, I must point out that compiling Csound5 requires a number of new tools. For the basic build, you need Python 2.3, the SCons build system, the libsndfile soundfile I/O library and the PortAudio/MIDI real-time I/O system. You also need the FLTK graphics toolkit if you want to enable Csound's graphics opcodes. To build the CsoundVST GUI, you also need the SWIG interface generator and the boost libraries for C++. SCons does a good job of sorting out dependencies, but many of the components required for a full build are not included with mainstream Linux distributions. Therefore, it is up to the user to install and configure correctly the needed software.
Despite its dependencies, actually building Csound5 is not especially difficult. Run scons -h to see what Csound-specific options are available and then run scons with your selected options. For example, on my underpowered laptop, I build Csound5 without CsoundVST like this:
scons buildCsoundVST=0
To install Csound5, I become root and run this command:
scons buildCsoundVST=0 install
To clean the sources, I use scons -c. Nevertheless, putting together all the pieces necessary to get Csound5 up and running is a non-trivial task. If you are not accustomed to compiling programs from source code, you may want to wait for the release of public binaries. Until then, your only other option is to compile Csound5 from sources.
Classic Csound processes two files created by the user, an orc file, which is the Csound orchestra or the instruments; and the sco file, which is the score performed by the orc file instruments. The modern approach dispenses with this dual-file method and utilizes what is known as the CSD file, an XML-like file format that includes both the orc and sco file contents as well as the command-line options required to render the file to sound. Here's a trivial example in Csound's classic mode:
;;; simple.orc
sr=44100 ; sample rate
kr=441 ; control rate
ksmps=100 ; number of samples per control cycle
nchnls=1 ; number of audio output channels
instr 1 ; begin instrument block
kamp = p4 ; amplification value (k = control-rate signal)
kfreq = p5 ; frequency value
ifn = 1 ; stored function table number (i = init-time value)
aosc oscil kamp,kfreq,ifn ; invoke oscillator opcode (a = audio-rate signal)
kenv linseg 0,p3*.50,1,p3*.50,0 ; create an envelope
aout = aosc*kenv ; scale oscillator output by envelope
out aout ; send it out as an audio signal
endin ; end instrument block
;;; simple.sco
f1 0 8192 10 1 ; store function table #1, a sine wave
; The following event statements provide data for instr 1's parameters.
; These values are known as p-fields (parameter fields). The first three
; fields are fixed-definition fields, where p1=instrument number,
; p2=start-time, and p3=duration. The definitions for all other p-fields
; are arbitrary. See instr 1 for the meaning of p4 and p5.
i1 0 1 8000 440
i1 1 1 9000 494
i1 2 1 9500 554
i1 3 1 8500 440
e ; end score
This code represents two separate files. To create sound from them requires compiling them with the Csound binary, as follows:
csound -o devaudio -d -m0 simple.orc simple.sco
In this example the audio data is routed to the real-time audio output device (devaudio). The -d and -m options reduce graphics and messaging for better real-time playback. Csound provides many other command-line options; run csound --help for a complete list.
The more modern approach combines all of the elements above into a single unified file format that Csounders call a CSD file. Here's the code above translated to the CSD format:
<CsoundSynthesizer>
<CsOptions>
;;; Command options for simple.csd
-o devaudio -d -m0
</CsOptions>
<CsInstruments>
instr 1
kamp = p4
kfreq = p5
ifn = 1
aosc oscil kamp,kfreq,ifn
kenv linseg 0,p3*.50,1,p3*.50,0
aout = aosc*kenv
out aout
endin
</CsInstruments>
<CsScore>
f1 0 8192 10 1
i1 0 1 8000 440
i1 1 1 9000 494
i1 2 1 9500 554
i1 3 1 8500 440
e
</CsScore>
</CsoundSynthesizer>
Notice that the header block is not absolutely necessary; Csound applies default values for the rates and channels. Also notice that the CsOptions block does not require an explicit statement of either the Csound binary or separate file names for the orc/sco contents. Use the command csound simple.csd to run this file. Options placed on the command-line override definitions found elsewhere, such the CSD CsOptions block, defined by an environment variable--Csound has a number of them--or in your ~/.csoundrc file. You can place your favorite options into the .csoundrc file for automatic reuse. Mine looks like this:
-+rtaudio=alsa --expression-opt -odac2 -d -m0 -M0
These options tell Csound to select ALSA for my sound system, optimize expressions for faster rendering, utilize the third audio device in my system for audio output (dac2 is my M-Audio Delta 66), manage display and messaging output and select the first available MIDI device for MIDI input (-M0 is the external hardware MIDI port on my SBLive). Other possible options include selections for JACK audio support, a MIDI output device and buffer settings for optimal use of your soundcard. Again, see csound --help for details regarding Csound's runtime options.
Similis sum folio de quo ludunt venti.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- RSS Feeds
- Readers' Choice Awards
- Tech Tip: Really Simple HTTP Server with Python
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?



1 hour 13 min ago
1 hour 46 min ago
4 hours 9 min ago
4 hours 12 min ago
4 hours 14 min ago
8 hours 38 min ago
10 hours 29 min ago
15 hours 43 min ago
18 hours 54 min ago
21 hours 10 min ago