Linux Music Blossoms with Rosegarden

When it comes to producing music with Linux on a professional level, Rosegarden includes the basic features that you would expect to find in a commercial music sequencer and scoring package: MIDI and audio recording and sequencing, sound effects and synth plugins, and a score editor. The array of additional stuff this free program offers is staggering when one considers that it is, as of this writing, on the eve of its version 1.0 release.

"I bought a magazine the other day that had tutorials about composing with each of the most common commercial sequencers for Windows and Mac, and almost everything in it could have been done using Rosegarden," says Chris Cannam, a 32-year-old software engineer in London, England.

A School Project

As a student at Bath University in 1993, Cannam and fellow student Andy Green started Rosegarden as a school project under the sponsorship of Prof. John Ffitch (a maintainer of and expert on Csound). They built an Athena-Widget-based music sequencer and score editor. (On a code level, this original version of Rosegarden has little in common with today's namesake.)

Throughout the early phases of its more recent development, the developers modeled Rosegarden after commercial sequencer applications, but only in a general sense. The Rosegarden developers studied the user interfaces of commercial sequencers such as Cubase and Cakewalk because their goal was to appeal first to musicians, not just geeks. They agreed from the start that Rosegarden should sport a simple, consistent, and friendly interface, while presenting the same level of functionality of a professional program.

"In the end, you can't really be very original when writing a sequencer. Musicians have pretty much all the same expectations when looking at such an application," says Guillaume Laurent, a 34-year-old software engineer from Cannes, France, who contributed to the design and user interface of Rosegarden.

Faster Progress with KDE

Rosegarden is written in C++, which Laurent describes as the "only viable choice" when building large desktop applications on Linux. They decided on an object-oriented language that included a good graphic toolkit and was popular enough among the open source community to encourage those outside of their team to contribute to the code. C++ "delivered the speed we needed, while offering the object-oriented design tools you can't really afford to ignore with a job of this size," says Richard Bown of Taunton, Somerset, England. The 33-year-old software engineer contributed to several areas of the Rosegarden code.

Rosegarden incorporates several libraries, and most are expectedly audio/sound-related: ALSA and JACK as base MIDI/audio layers, and the open source plugin LADSPA. Initially, the Rosegarden team developed for the KDE aRTS interface, but the ALSA/JACK combination delivered more of the solution they required.

Figure 1. The Rosegarden interface, version 0.9.9. Click for full-size image.

"KDE provided us with a development framework that let us concentrate on Rosegarden issues, not KDE ones," says Laurent. "At the time, CORBA and gtkmm required us to constantly update GTK and GNOME libraries, and then gtkmm itself, so none of us ever got any real work done."

"We do get a surprising amount of flack over the fact that we use the KDE libraries," says Cannam. "It staggers me that people would reject a program that they claim they would otherwise find interesting and useful, just because it doesn't use the libraries or programming language that they most approve of. Our aim is to reach a greater audience of people whose first priority is actually to use the software, rather than study it and think about how they would have written it."

A technology developed by Cannam and another programmer outside of the Rosegarden team as a separate project became one of Rosegarden's unique features: a DSSI plugin API. (DSSI is an API for synthesis plugins, similar to--and derived from--the LADSPA plugin API, and comparable to VSTi on Windows.) Others can use this for their own projects, but for now Rosegarden is the only DSSI-capable sequencer.

The DSSI plugin "was designed to be attractive and simple to plugin authors," explains Cannam. "It was actually rather hard to implement in Rosegarden, and there's certainly nothing specific to our application about it. I'm actually concerned that an association with Rosegarden might have limited its appeal to the authors of other [music applications] and, consequently, to plugin authors as well. That would be a shame, because it's the only current workable proposal for sample-accurate synthesis with custom GUIs and easily reproduce-able configuration data on Linux."

The "Freight Train" to Version 1.0

During early development, two challenges cropped up in writing the code that handles communication between the GUI and the sequencer (originally done entirely through DCOP, but now through DCOP and mmap()'ed files) and the mechanism to keep several views in sync while editing the same section of a composition. "Both were pretty hard to get right, and in the second case we probably didn't get it that right, even though it's working correctly--I hope," admits Laurent.

"The biggest technical challenge I have faced was fixing the code that decides how to spell enharmonics and write accidentals," says Michael McIntyre, a "30-something" truck driver by trade from Virgina, who contributes code and bug fixes to Rosegarden. "I wound up replacing all of the original broken elegance with code that has all the delicate finesse of a freight train."

For Bown and Cannam, simply polishing Rosegarden's audio engine itself into a workable state was vexing, and particularly trying for Bown--the effort burned him out. "Chris picked up the difficult audio stuff where I was struggling and really turned it into a super engine, which not only integrated to sample level with the MIDI drivers, but also provided synchronization and softsynth integration all at the lowest engine levels. An excellent piece of work. Before that, I felt a bit beaten by it all, but I think it goes to prove that there's only so much you can do yourself," says Bown.

Sound on Linux: Geek-Only Turf

Some limitations do exist with Rosegarden. Its most obvious failing as a notation editor is its inability to handle part writing or complex flow control (like al fine, nested repeats, or repeats with multiple endings).

Additionally, the "segment canvas" (the main window in which you draw segments of events within tracks) isn't flexible with regard to the length of a composition. This is due to the program using Qt's QCanvas. Laurent is presently rewriting the segment canvas, using a specialized widget. He anticipates that he will probably have to do the same for Rosegarden's "matrix" (piano roll) and notation-view windows. "We initially used QCanvas for all of these, and I was totally sold on it. But even though QCanvas gave us a jumpstart, it doesn't fit our needs very well," he says.

However, the biggest problem has nothing to do directly with Rosegarden: it's setting up sound cards easily on Linux. Most of the technical questions users ask the Rosegarden developers relate to this. "I really hope the sound card vendors will give the ALSA guys all of the specs they need to write full-featured drivers, and that the whole ALSA/JACK/LADSPA framework will become easier to deal with. Right now, it's really a geek-only turf," says Laurent. "There are positive points! Seriously though, we've worked around a lot of problems," says Bown. "We now employ multithreading in the sequencer engine and selectively in the GUI, and use some rather cunning Qt/KDE shortcuts to achieve our requirements. I would still say that overall performance is our biggest bugbear--and I'm keen always to make the UI more responsive. However, the app is very usable and very powerful."

Growing After 1.0

The to-do list of features to add to future versions of Rosegarden is as extensive as the application itself:

• Multi-part score notation via layered segments
• Scripted segments for automated composition or analysis
• Tempo tracking and groove-template quantization
• Percussion editors
• Guitar tab
• Chord analysis
• Microtonal notation and performance
• A multi-segment matrix editor
• Fader automation
• A category-tree-based audio effects picker, audio effects on busses, effects on master out, send effects, effects on segments rather than tracks, and effects freezes
• Fancier graphics, particularly for fader and meter widgets

But wait--there's more! McIntyre muses, "I want to make it possible to select on a whole range of new search criteria, such as picking out all of the notes with certain marks, notes whose performance duration differs from their display duration, etc. I want to build the necessary infrastructure to make it possible to do a complete and friendly job of changing programs in the middle of a segment; when changing a string part in and out of pizzicato, for example. This is currently possible, but it's extremely crude, and needs massaging."

"Another really cool feature I'd like to have is automated composition, a la Band in a Box," says Laurent.

Cannam responds, "How many of [these will be] 1.1 features, rather than 1.2 or 2.0 or 17.0? We don't know yet."

Either way, you can expect the aptly named Rosegarden to grow and flourish.

Developer Interview: Rosegarden

Howard Wen: A lot of music production applications have been developed specifically for Linux. Why do you think there has been such active development in music applications for Linux?

Richard Bown: Every geek seems to play an instrument. Music geekery seems to be high on the list of things to do in the spare time we have. I always wanted to sequence audio and MIDI, but was bored having to learn the complex ways around the most powerful apps. A lot of similar people had similar scratches to itch, I think.

Michael McIntyre: I would imagine that what fuels this development is probably the same thing that fuels my own interest in this project. We are "hacker-musicians," or "musician-hackers," developing tools for our own use, first and foremost, on the platform we prefer to run. A significant amount of my own involvement here has been motivated purely by self-interest: I want it; it doesn't exist, so let's do something about that.

Guillaume Laurent: If you restrict yourself to apps that have reached a reasonable degree of usability, there aren't that many. Note that if you compare to Windows or OS X, we're still kind of lagging behind, to say the least.

Second, even though there's bound to be some overlap in features, most of the apps have a pretty narrow field of focus. For instance, Ardour is mostly aimed at audio, while Rosegarden is mostly a sequencer with audio as a secondary feature. In the context of a recording studio, this kind of modularity is not bad. It would be best, UI-wise, if all of these apps shared the same toolkit. But even in a hardware-based studio, each rack unit has a completely different UI than the others, so in practice, it's not a big problem.

Chris Cannam: Since Linux applications are usually free software, their quantity is exaggerated because you get to see the half-finished and the never-to-be-finished applications, as well as the working stuff. I could probably name all of the sizable, GUI-based music applications for Linux that are in active development, and it would only take me a couple of minutes. That doesn't suggest any more activity than on any other platform.

Where Linux does come out well--and this is really important to users as well as developers--is in interoperability, flexibility, and durability of code. There are various reasons for this: signal-processing code is naturally recyclable, so the benefits of making open source code are maximized; on a platform without major commercial influence (in the audio field, at least) you don't so easily get entrenched competing standards that are only standard to a particular company and their users; and old code can be kept alive for as long as there's a significant interest.

So you have LADSPA plugins built on other LADSPA plugins, applications built on plugins, toolkit-style applications like Ecasound and Snd that have been around for a long time and are still winning new converts, sequencers outputting to score applications outputting to typesetting applications--and you have things like the JACK audio connection toolkit, which has become a standard by being the right solution, being simple to code for, and being good, rather than because of commercial concerns.

These are genuinely interesting things for users as well: JACK, in particular, can do amazing things for the usefulness of nearly any audio application that supports it--it permits any audio input or output from any application to be connected to any other, with very little overhead. And on Linux these days, almost all serious audio software supports it, so the things you can do are almost limitless.

HW: How would you differentiate Rosegarden from other Linux music applications that are similar?

GL: Notation is our strongest point. Integration with KDE is another good feature.

RB: We've very focused on quality and limiting functionality when it may clutter the UI. We've been very hard to bargain with as a development team, because we've usually got strong views on how the project should progress.

CC: Rather sadly, it seems we hardly need to. There only is one actively developed application that's really similar to Rosegarden, and that's MusE. The most obvious difference is that MusE doesn't have a score editor--it used to, but they removed it.

Otherwise, as Richard said, the main thing about Rosegarden is that we think carefully about the user interface.

HW: Besides its user interface, what else would you like others to pay notice to the most about Rosegarden?

MM: Many of our most striking features revolve around our ability to preserve a MIDI performance intact, while also rendering it into perfectly legible notation. We can quantize based only on display durations, and we have nifty tools for performing fancy ornaments that are written in the usual way (with squiggly lines over a note that has a sane duration), instead of being represented by the ton of nasty-looking gobbledygook that people actually play when performing these various ornaments.

As a user of such software over the years, converting a MIDI recording or an imported file into legible notation has always been a serious challenge. Rosegarden does a very tidy job, although it must also be said that sometimes it takes quite a lot of doing to get good results. None of this stuff is a panacea, and it is still hard to turn a really wild performance into tidy notation.

CC: Rosegarden is the only Linux music application designed to be an immediate alternative to the major brand-name sequencers for other platforms, designed to be a useful compositional tool for people who know classical notation, and designed with usability and learn-ability in mind from the outset. It's also the largest and most complex Linux music application. In other words, it's an immensely ambitious project that's already really useful to musicians, and I want people to start to look at it in those terms, rather than the sort of technology-oriented view that Linux developers are more inclined to.

HW: If somebody wants to contribute to your project, what skills from them could you use now?

MM: This project demands both a thorough knowledge of C++ and KDE programming, and a fundamental understanding of music. It helps if you "speak" MIDI, too. If anyone fits this bill, we'll find something for you to do. There's plenty of work to go around.

GL: Ever since our first public release, we've received few external contributions. I discussed with David Faure about this once, and he told me he had the same problem with KWord and KOffice. Contributions are scarce, and contributors are very hard to keep around.

There's no mystery: projects this size are hard to get into, and we neither have the time to fully document the code, nor to constantly guide newcomers. Plus, these contributors face the same problem we have--namely, time: not having enough, and having it fragmented. It's already hard for us to work in these conditions on code that we wrote. And, no, there's no silver "make things modular" bullet. [Rosegarden] is a large GUI full of features; you can modularize it only so far.

So the main skill would be: the ability to quickly find one's way within 200,000 lines of poorly documented C++ code.

HW: What are the issues one should be aware of when developing code that deals with sound under Linux?

MM: The key is to overbuild and to make as few assumptions as possible. Whatever it is you don't think anyone will ever try will be tomorrow's bug report or feature request. Nearly every major issue we have dealt with has been a side effect of assuming "no one would ever want to do that anyway." Plan big, write big, assume the most ridiculous set of circumstances imaginable, and leave everything as open-ended and flexible as possible.

RB: As in any development environment, you've always got to keep an eye out for the latest developments, but don't let them drive your work unless there's a "win" in there for you. There are a lot of new APIs appearing all the time, so you have to be clear on what you want to do and find the best fit for the lower levels, drivers, etc.

HW: What advice do you have for those who are interested in developing applications that address the creation of music and the manipulating of sound, regardless of platform?

GL: We seemed to have made some good choices about our data structures. For events (as in MIDI events, only more general), we quickly realized that having to maintain them sorted time-wise would be a chore. So we chose a structure that would do that for us--namely, the STL's multiset.

We also chose not to have a base Event class with lots of siblings (NoteEvent, TempoEvent, etc.) because that quickly leads you to the "Fragile Base Class" problem, another maintenance chore. Instead, we have one that is flexible enough to represent any event, that is a class with a type field, and a properties table (a hash map, in our case). That may sound "anti-OO," but I believe it's actually the only way to go because of the flexibility it gives you.

You will want to keep the core data structures completely abstract from the GUI, but that goes without saying.

For audio, and moving large blobs of data around, mmap() is your friend.

CC: Don't forget that other people--non-programmers--likely know a lot more than you about many of the things you're interested in. Most of the basic techniques involved in a computer audio application are at least 20 years old; most of the music theory, of course, is much older. Even if you think you're doing something quite new, it does pay to ask around first.

Howard Wen is a freelance writer who has contributed frequently to O'Reilly Network and written for Salon.com, Playboy.com, and Wired, among others.

Return to the Linux DevCenter.