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.
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
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
| 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 |
| Trying to Tame the Tablet | May 08, 2013 |
| Dart: a New Web Programming Experience | May 07, 2013 |
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- New Products
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- Validate an E-Mail Address with PHP, the Right Way
- New Products
- Tech Tip: Really Simple HTTP Server with Python
- Trying to Tame the Tablet
Enter to Win an Adafruit Prototyping Pi Plate 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 Prototyping Pi Plate 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
- Next winner announced on 5-21-13!
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.



2 hours 34 min ago
2 hours 56 min ago
3 hours 7 min ago
3 hours 11 min ago
3 hours 41 min ago
6 hours 32 min ago
7 hours 8 min ago
7 hours 9 min ago
7 hours 10 min ago
7 hours 11 min ago