Thursday, August 30, 2007

Music Control Languages: Specialised Tools

In the first article in this series, I set the criteria for my examination of audio control languages. In this second part I examine the specialised tools available for the purpose. The series will then be concluded with a look at Python-specific solutions.

Though the last few items are subjective and optional, all products discussed meet the first four criteria unless otherwise mentioned:
* open source
* free of charge
* cross-platform (Mac, Windows, LINUX)
* programmatic control with OOP paradigm
* mature implementation
* efficient resource handling
* powerful, expressive, clear syntax
* strong user community

A good amount of software has emanated from IRCAM in France, possibly the foremost institution of electro-acoustic music in the world. Everyone from Pierre Boulez to Aphex Twin has been shaped by IRCAM. So it makes sense to start our examination of software with their graphical audio software Max/MSP. This is popular, but not free. jMax can also be quickly ruled out, since it is a non-OOP visual programming environment for building interactive real-time music applications. Though it is free and open source, the Windows version is only a beta and might not be robust enough for critical use.

OpenMusic is another IRCAM package, also graphical, running only on Macintosh (Linux port is on the way). I include it here for completeness only.

Pure Data (PD) gets the thumbs up from its users. It too derives from IRCAM work on Max. PD may be used for audio and MIDI processing, but also graphics and video (it has a fast dedicated openGL library, GEM, for this purpose). The forum is active and there are many resources on the web, though the home page does link to much dead content.

However, PD is a "patcher" programming language, in which one graphically links together blocks that perform different functions. It is not object-oriented but is important enough to consider, especially as regards the large number of available extensions. For example, RTC-lib, the Real Time Composition Library, provides high-level compositional algorithms. There are also mature interfaces to devices such as the Arduino.

So how do PD and Max/MXP differ? The latter has better documentation, more bundled extensions and a smoother usability experience. Plus it has some programmatic niceties, at least according to those who know it well. For example, the order of processing is from left to right in the Max flowchart, whereas in PD it depends on when you created the items. That is, items you added to the flowchart first when building will execute first when running! That makes zero sense.

Moving across the water we next look at Processing, a programming language which sprang from the MIT Media Lab. Designed specifically for interactive application it is written on top of Java, and has the distinct advantage of being able to run directly in a web browser. There is a good amount of support on sites like Processing Hacks. A MIDI library is available, as is the Sonia Library for advanced capabilities like multiple sample playback, realtime sound synthesis and analysis.

However Processing is still in beta, and this shows in its inefficient implementation. According to this thread it's not quite ready for prime time in its performance and memory handling. But if your emphasis is on visually interactive applications (perhaps for your mobile phone) you should give it a look.

SuperCollider is an interpreted object-oriented language that has two components: a client which communicates with a realtime sound synthesis server via OSC. This architecture is flexible enough to permit "live coding", changing code in real-time as a performance tool. Code objects and process declarations can also be shared and modified over a network.

Because SuperCollider has support for MIDI and serial port I/O (LINUX only), it can be used to control, or controlled by, pretty well any hardware device. So you can scratch with your Wii remote, should that be your thing.

The Windows version, known as Psycollider, is in beta. The fact that the last version update was over a year ago is not encouraging.

ChucK is a "strongly-timed" audio language optimised for real-time synthesis, composition, performance and analysis. It supports MIDI, OSC and multi-channel audio through a command-line or Integrated Development Environment (IDE). Live coding is supported.

Several of the programming paradigms in ChucK are novel. Unlike other audio systems that have a separate audio signal and control signal, ChucK has a unified timing mechanism. One of the built-in types is the "shred", a non-preemptive process with its own namespace. (However, other than this and the public space, there is no other control for namespaces.) Shreds can be sporked (I kid you not) which essentially means instantiated in the virtual machine. Shreds are automatically synchronized and may be scheduled (though ChucK calls it "shreduled" -- silly rabbits!).

Garbage collection is by reference counting, but this is still being implemented. In fact in many places in the documentation there's the phrase "not completely implemented" or even "will leak memory". The last version was 23 August 2007. With further active development I hope ChucK will be ready for prime time soon.

Csound is the grand-daddy of computer programming languages, its genesis reaching back before the nineties to Music360 in 1957. There are vast resources available, but Csound is closer to a lifestyle than a programme, requiring a dense incremental development cycle. The language itself is limited, a fact acknowledged by the Csound community, which has responded by embedding a Python interpreter. This creates a somewhat complicated schizoid syntax for coding.

Python can also be used on the "outside" of Csound, to manipulate CSound files, speeding the creation of sounds. The article Sound synthesis with Csound contains the required module.

A number of front-ends have been developed to ease development. For example, Cabel provides a GUI with Python script control.

While I am sure that a given collection of tools might make work in Csound highly efficient, determining what that might be is the work of months. Unless one's full-time job is computational music, it's difficult to recommend Csound. (I can see the flames igniting from here.)

So, conclusions?

* Pure Data is a rough-hewn many-faceted system that is the best of the free graphical solutions. If you want to spend money get Max/MXP instead.

* SuperCollider has a solid open architecture that suits networked and multi-user solutions, so long as one is willing to forget Windows.

* ChucK is still a work in progress but its "strongly-timed" declarative syntax is an innovation. As is some of the nomenclature! Watch this one.

* I will use Processing to hack my phone into a musical instrument, but not use it for mission-critical work as of yet.

* Csound is what you should use once you get employed by a university to make sounds.

Addendum: Sometime after I first wrote this document I came across the Wikipedia "Comparison of audio synthesis environments" here. An exhaustive list of software for algorithmic composition is located at This includes many products not on my list but none that meet my criteria.

I thank the Arts Council for their support in this research.



robin said...

Yes, I should have mentioned Blue, which looks totally cool for those wanting to operate on a timeline basis, like a traditional multitrack recorder. Though of course with massive scripting possibilities.

Anonymous said...

Supercollider is divided into the server SCserver and the language SClang, they comunicate with OSC protocol. It is only the lang that it is not fully implemented under windows. So the SCserver can be controlled from python via OSC. SCServer is 100% crossplatform and it will run on windows, Linux and OSX. There is a python library that aims to use Python instead of SClang to control the SCserver, it was at but the maintainer seems to have changed the url recently. We did an app using this technique if you are interested check it out here it is called Slicer

robin said...

The ixi software looks pretty cool. I tried slicer for a different purpose some time ago and my sound card was not detected, the mouse didn't do much, and it was under-documented. Plus, as you say, not all the components are available at this time. I rather got the feeling win32 support was an afterthought.

Nonetheless I am glad to hear that it *is* possible to communicate with the supercollider server from Python, and might give this a shot for a future project.

Anonymous said...

Agreed that the Windows port of SuperCollider is not ready for prime time... one factual correction, though -- the last update was December 2006, rather less than "more than a year ago."

File is named, i.e., Dec. 20.

Progress is slow on that platform because the guy who was working on it decided (wisely, I would think) that he can no longer postpone his Ph.D. to update it.

I personally would love to find a Windows-savvy developer who can fix the handful of nasty bugs remaining.... no idea where to look though.

robin said...

Ah, sorry, my date math was off about 4 months. :-)

watson said...

this is a great review ... thank you for posting it.

Anonymous said...

Having done the work of months (took me years), the CSound related tools I find most useful are cmask (writing score files) and Audacity (normalization and mp3 conversion). The rest can be done in CSound. Can also be used as a Python module. Any universities out there got an opening for a csound hobbyist ?

Post a Comment