Csound for Linux

Mr. Phillips discusses some history as well as what's happening now in the Linux Csound world.

Csound is a music composition and sound programming language originally written by Barry Vercoe at MIT. As Nick Bailey pointed out in his October 1998 LJ article “Sculptor: A Real Time Phase Vocoder”, Barry's original MUSIC11 program was eventually ported from PDP-11 assembler to UNIX C, where it became Csound. MUSIC11 was derived from the pioneering MusicV program by Max Mathews, perhaps the most revered “Founding Father” of computer music technology.

One of MusicV's major innovations was the implementation of the unit generator, a “black box” concept that allowed great extensibility to the language. A unit generator can be a signal generator or modifier, a patching opcode, a sensor, or it can provide sound file I/O and signal display types. Csound has evolved into a notable successor to Music V, quickly accommodating new synthesis methods and DSP algorithms. It is now at the cutting edge of modern computer music software. Linux Csound has done more than simply kept pace with that evolution—it offers capabilities not found with versions available on other platforms.

Enter Linux

In 1996, I wanted to try out the Linux OS. I knew certain software synthesis languages would run under it, and those languages were not available for DOS/Windows machines. Although Csound does indeed run under Microsoft operating systems (and many others), I was interested in seeing how well it would run under Linux. Jonathan Mohr had already added the real-time audio support for Linux, but I immediately discovered I had stumbled upon another big “DIY” (do it yourself) project. The source code available from the Bath, UK FTP site (the primary repository for the “canonical” packages) was a general UNIX package, without Linux-specific Makefiles or any other compilation amenities. Although I was a novice at both Linux and the C programming language, I jumped in and started thrashing. With good assistance from John Fitch (maintainer of the Bath site and the canonical sources) and the helpful members of the Csound mail list, I finally produced a working set of Makefiles for the entire source tree. I soon had a fast Linux Csound with full support for X displays, real-time audio output and all the current opcodes. Professor Burton Beerman kindly provided an FTP site for my Linux Csound packages on his MusTec server at Bowling Green State University, and for two years I maintained the public version on that site and at Bath.

CSound in a Nutshell

Linux CSound: the Plot Thickens

Early in 1998, I received a message from Professor Nicola Bernardini at AIMI (Associazione di Informatica Musicale Italiana). He had thoroughly rewritten the Linux Csound Makefiles and wondered if I might be interested in adding them to the source package. His offer came at a good time, as I knew the code maintenance needed a more solid structure. Nicola's expertise was just the right factor appearing at just the right moment. His Makefiles enabled me to quickly prepare a variety of distribution packages (with or without X support, static build or shared lib, real-time audio enabled/disabled, etc.) and compile a more complete build of the source tree. Most importantly, the Makefiles created libcsound.so, a shared library which drastically reduced the binary's memory footprint (from about 450KB to less than 20KB).

Real-time Linux CSound

Around the same time, developer Gabriel Maldonado wrote a set of MIDI output opcodes, allowing Csound to be used as a MIDI composition/control instrument. Csound already accommodated MIDI input, directly from /dev/midi or from a Type 0 Standard MIDI File (see Real-time Midi Input). Gabriel's opcodes are different: they permit exploration into MIDI composition algorithms simultaneously with the rest of Csound's real-time I/O. Hypothetically, it would be possible to have a MIDI device controlling one Csound instrument while another instrument sends its output to devaudio. Given support for a full-duplex sound card, it should even be possible to have asynchronous I/O for both the MIDI and the audio ports.

Alas, no routines had been written for Linux Csound that would accept the data from Gabriel's opcodes and send it out to the MIDI port. After studying John Fitch's code for the Windows Csound MIDI output handler, I decided to try writing the appropriate calls for Linux. I fumbled around with the OSS/Free API and eventually wrote the code needed to activate the requested MIDI interface and accept the control data sent to it from the Maldonado opcodes. Linux Csound was as up-to-date as any other version, and the necessary code for MIDI output had been trivial to write, consisting primarily of a few calls to the sound card API macros.

______________________

White Paper
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

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.

Learn More

Sponsored by AMD

White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

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.

Learn More

Sponsored by DLT Solutions