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:
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.
|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|
|Trying to Tame the Tablet||May 08, 2013|
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- New Products
- The Pari Package On Linux
- New Products
- Home, My Backup Data Center
- This is the easiest tutorial
2 hours 34 min ago
- Ahh, the Koolaid.
8 hours 13 min ago
- git-annex assistant
14 hours 12 min ago
- direct cable connection
14 hours 35 min ago
- Agreed on AirDroid. With my
14 hours 45 min ago
- I just learned this
14 hours 49 min ago
15 hours 19 min ago
- not living upto the mobile revolution
18 hours 11 min ago
- Deceptive Advertising and
18 hours 46 min ago
- Let\'s declare that you have
18 hours 47 min ago
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!