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.
|Bitcoin on Amazon! Sort of...||Sep 28, 2016|
|Free Today: September Issue of Linux Journal (Retail value: $5.99)||Sep 27, 2016|
|nginx||Sep 27, 2016|
|Epiq Solutions' Sidekiq M.2||Sep 26, 2016|
|Nativ Disc||Sep 23, 2016|
|Android Browser Security--What You Haven't Been Told||Sep 22, 2016|
- Free Today: September Issue of Linux Journal (Retail value: $5.99)
- Bitcoin on Amazon! Sort of...
- Android Browser Security--What You Haven't Been Told
- Epiq Solutions' Sidekiq M.2
- Identity: Our Last Stand
- Nativ Disc
- The Many Paths to a Solution
- Securing the Programmer
- Tech Tip: Really Simple HTTP Server with Python
Pick up any e-commerce web or mobile app today, and you’ll be holding a mashup of interconnected applications and services from a variety of different providers. For instance, when you connect to Amazon’s e-commerce app, cookies, tags and pixels that are monitored by solutions like Exact Target, BazaarVoice, Bing, Shopzilla, Liveramp and Google Tag Manager track every action you take. You’re presented with special offers and coupons based on your viewing and buying patterns. If you find something you want for your birthday, a third party manages your wish list, which you can share through multiple social- media outlets or email to a friend. When you select something to buy, you find yourself presented with similar items as kind suggestions. And when you finally check out, you’re offered the ability to pay with promo codes, gifts cards, PayPal or a variety of credit cards.Get the Guide