MusE: MIDI Sequencing for Linux

Frank Neumann, a 36-year-old computer scientist from Karlsruhe, Germany, and one of the developers of MusE, sums up the current state of music production applications for Linux: "It's always a nice warm feeling when you show an application like MusE to people and they just go, 'Whoa--I didn't know Linux audio stuff was already this far!'"

The application, a MIDI/audio sequencer popular within the Linux music community, began in late 1999 with the work 49-year-old Werner Schweer of Bielefeld, Germany. Schweer still leads development today. Fellow MusE developer Robert Jonsson describes him as "the fastest coder I know. The pace of development is, thanks to Werner, as always, furious!"

MusE came about from the lessons Schweer learned when he first tried to develop a MIDI/audio sequencer for Linux six years ago. He created this precursor to MusE as two separate programs that worked together. The GUI was in a Tcl/Tk application, and the real-time MIDI sequencing was a kernel driver.

"It turned out that I was not able to manage a Tcl/Tk script beyond a specific size. Tcl/Tk is not well suited for really big programs," recalls Schweer. "For the kernel driver, it was difficult to define a suitable interface between kernel and user space. Both programs failed and were never published."

Two developments in the Linux scene changed the situation: the release of Qt enabled Schweer to write big GUI programs in C++, and the real-time scheduler added into the Linux kernel eliminated the need for a special kernel driver to implement MIDI sequencing. These two technologies encouraged him to try again, and MusE finally came into being.

Thanks to the prolific coding skills of its creator/lead developer, MusE's evolution is frequent. Figure 1 shows the new user interface design implemented for version 0.7.2.

Figure 1. The new interface in MusE 0.7.2; click for full-size image

Schweer spoke with us about the development and technology behind MusE, as did Neumann, Jonsson (a 33-year-old computer engineer from Skellefte, Sweden) and another member of the MusE team, Mathias Lundgren, 29, also from Skellefte.

O'Reilly Network: Did any other program inspire MusE?

Werner Schweer: MusE was inspired mainly by Cubase, but also by other similar programs like Logic and Cakewalk.

Frank Neumann: Anyone with some experience in Windows sequencing software will see the similarity with Cubase. This can be seen in such obvious things as the Transport (a small window for controlling playback and recording) [and] also in finer details like the keyboard shortcuts, context menus in the editor, the Track Info, and probably several more GUI elements.

It is not trivial to state whether following Cubase so closely was a good idea or not; [it] revolutionized the music world with the Track/Part concept back in the 1990s when the first version of Twenty-Four (a predecessor of Cubase) came out. Arranging/recording music this way feels quite natural nowadays.

Robert Jonsson: There are several commercial packages that have similar workflow--call it the "audio workstation paradigm." This way of working has influenced MusE a lot.

ORN: What language do you use to write MusE? Why?

Schweer: MusE is written in C++. It took years of practice to get really good at using a specific programming language. So when starting a new project, you simply use what you know best. In my case, it's C++.

Jonsson: For a real-time audio application, there are basically only two choices that make sense because of the real-time requirement: C or C++. I find C++ a better choice when doing large-scale development, and MusE is pretty big.

Neumann: I also think that it was a very wise choice, as an application with roughly 90,000 lines of code has to be very well designed in order to remain maintainable.

ORN: What external libraries does MusE use that you didn't originally develop? Why did you choose them?

Jonsson: MusE uses a lot of external libraries. Some were chosen because they suit MusE best, some because they are the de facto standard in Linux:

• Qt, the GUI framework that MusE is built around.
• ALSA, the MIDI framework that is standard on Linux.
• FST, the VST compatibility library, adds support for VST synths and plugins.
• libsndfile, which adds support for reading and writing various audio file formats.
• JACK, the best, and de facto standard, framework for interoperation of sound applications.
• LASH, a session-handling system that allows extending the loading and storing of projects systemwide.

Schweer: The biggest dependency is the Qt library. I have some years of experience with x11 programming using the xt and the motif library. Compared to motif, which is a real pain to use, Qt is a fantastic piece of code. Without Qt, I would not have started MusE.

Originally, MusE used ALSA also for audio input/output. Later versions added JACK audio input/output. In current versions, I dropped ALSA audio input/output mainly to reduce the maintenance overhead.

Neumann: libsndfile is currently the best audio file import/export library.

MusE 0.7 and above are now JACK-only; older versions could output their sound directly to ALSA, but this is over now because the work to maintain both back ends was too much hassle.

ALSA--for MIDI input and output, there are no alternatives.

It's a little strange that, though MusE's internal file format is XML-based, no libxml or libxml2 appears in this list; Werner instead opted for writing the XML support himself.

ORN: Did you create any technology specifically for MusE?

Schweer: MusE contains some code and interfaces which could be interesting for other projects. There is MESS, the MusE Experimental Software Synthesizer interface, and the abstract widget library, which tries to "unbundle" some of the MusE internal widgets from MusE.

Mathias Lundgren: MESS, the interface for built-in softsynths, makes it very easy for a developer to focus on development of the synth, and its GUI itself, since the API gives the synth all the MIDI events and handles the IPC between the GUI and the synth in a smooth way.

Jonsson: Another interesting technology is the ability to specify GUIs for plugins using XML. The GUI is then rendered during runtime; this allows for adding customized GUIs for plugins which lack GUIs.

ORN: What have been the biggest technical challenges in the development of MusE?

Schweer: MusE is a multithreaded application and can be divided into two main functions:

1. A real-time sequencer, which plays events collected in a data structure (a "song").
2. An editor to manipulate the song data.

The design goal was to be able to manipulate all song data while the sequencer was running. This is not easy to do when you consider the real-time nature of the sequencer part, which means that you cannot use standard techniques, like semaphores, to lock critical code sections in a thread. This also means that you cannot use the standard memory allocator in the sequencer thread (no new/delete malloc/free).

Neumann: The biggest challenge was perhaps to find the best way between features and code stabilization. Sad but true--MusE has not been really stable for a long time, and this is not solely the author's fault: the development team is still very small, and 95 to 98 percent of the code was written by a single person.

Since Robert Jonsson took over the task of project manager, the whole project is getting more direction. I hope that this continues and at some point MusE really takes off.

ORN: What are the technical limitations of the current version of MusE?

Neumann: The number of tracks, parts, MIDI devices, audio samples, virtual instruments, etc. is only limited by the CPU and main memory at this time. There is a limit of four insert effects per mixer strip, but this could probably be changed easily.

Jonsson: There are a bunch of features missing in MusE, and even a few things that have been removed over the years, like MIDI-only mode, that we'd like to bring back.

MusE has gone through several evolutionary changes. If there are things we find we need to put in, we'll adapt. No feature is more than a rewrite away! And thanks to Werner, the fastest coder I know, we'll keep adapting when there are justified needs.

On the other hand, there are things we would like to fix faster than we currently can, since there are not enough people working on this project, like support for more architectures and improved support for Kernel 2.6 (though this is possibly out of our hands). But being short on resources is a problem for most projects, and it's not really a "technical limitation."

ORN: What is the present status of MusE?

Neumann: The current "stable" (0.7) branch could be described like this:

• Stable MIDI sequencing, talking to either external gear or software through ALSA.
• Mostly stable audio sequencing through JACK.
• A feature-rich and intuitive Qt-based user interface.
• Support for VSTi instruments through the FreeFST package using WINE.
• No really usable automation of mixers or virtual instruments yet.
• Stable timing dependent on a patched kernel.
• Somewhat stable, but not rock-stable.

Compared to 0.6.3: that one was quite stable with regards to MIDI, but only barely usable for audio.

The current development branch (on its way to 0.8) is very much a work in progress and will bring a reworked GUI, better separation of the GUI from functionality, more automation features, and (hopefully) better documentation.

Lundgren: Werner is working on a new GUI for the arranger, the main editor with all the tracks. This new GUI will include controls for the new automation engine. I think the automation, and the GUI for it, will be the main feature of the next stable release.

Jonsson: The current release, 0.7, is pretty solid and has a huge list of features. Basically, the goal is to become a complete virtual studio. MusE is already a long way toward achieving this goal.

One of the goals of 0.7 was to increase stability, which I think worked out nicely. I've used MusE a lot lately, and it is getting quite usable for the way I work.

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.