Csound for Linux
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.
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.
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).
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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SourceClear Open
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide