Paul Davis: an Ardour for the Challenge

It is no exaggeration to claim that Paul Davis' software is employed by every serious Linux audio user and developer.
Music Matters

DP: Have you pursued formal music studies at any time in your life?

PD: I studied flute in middle school, and in high school I used to mess around on our family piano. I also did a lot of tape machine experimental music—myself and several friends were part of a (culturally) very important “cassette swapping” network in the UK during the late 1970s that sanctioned all kinds of weird experimentation and noise making. My early taste in music was dominated by German electronic music, experimental composers and minimalism, which greatly affected what I wanted to try to sound like as a teenage “noise” maker. I tried to learn tabla about 15 years ago, but gave up realizing I was as hopeless as I feared. About seven years ago, I started learning cello, but when I noticed that despite being (relatively speaking) a person of considerable leisure time, I still did not practice till right before a lesson, I called it quits. It gives me a lot of joy that my daughter (now 13) has taken up cello and is entering a phase now where she is starting to sound quite pleasant.

DP: How important is a formal background in music for a programmer who wants to write music and sound software?

PD: Well, in one sense, almost none. Most of the problems when writing audio software are not about audio or music—they tend to be about computers and programming languages and mistakes that you or other people have made. But on a different level, having a clear understanding of the variety of musical structure around the world, and a real sense of how polyphonic music is composed both historically and today, can be really helpful in developing software that is actually useful to real musicians.

DP: What music do you prefer currently?

PD: My digital music collection has nearly 10,000 songs in it, and I have another 800–1,000 vinyl albums. It would be hard to tag it with a particular style, but on inspection, I have more music by ambient electronic musician Steve Roach than anyone else, and by some strange name-similar coincidence, the minimalist composer Steve Reich comes in second (though a distant second). When I work, I often tend to listen to drifting electronic soundscapes, though nearly as often I'm tuned into SomaFM's Groove Salad or Secret Agent stations. At other times, I could be listening to heavy dub reggae, Kurt Elling tearing up jazz standards, Carnatic Indian classical or Soul Coughing.

On Ardour and JACK

DP: Ardour 2 is rolling along nicely. What significant development remains for that branch of the Ardour Project?

PD: Not very much is planned right now. I think there will be a 2.5.1 release in the not too distant future [it was released in September 2008], and after that, it will be mostly bug fixes. It's possible we might add a few new features to get us to 2.6, but I don't see going much beyond that with the 2.x series.

DP: Ardour 3 is certainly one of the most anticipated packages in the world of music and sound software libre. What is its current status, and what major challenges remain before a release is scheduled?

PD: There is one immediate challenge, which is merging the changes between 2.4 and 2.5 to the 3.0 tree. A lot of work was done that touches many things that changed independently in the 3.0 tree, and as a result, the merge presents some major challenges. When 3.0 is released, it will have all the features of the most recent 2.x release.

More long-term than getting this merge done, we have three major areas to focus on. The first is getting 3.0 actually working at the same level of functionality as 2.x. This will take a lot of sustained and minor bug fixing to correct small things that got broken along the way. We also need to ensure that 3.0 can handle sessions created with 2.x—right now, this is not the case. And finally, we need to ensure that our initial release is actually useful for people doing MIDI sequencing. I imagine lots of evolution of our MIDI work flow, which is pretty different from most DAWs already, but we need to start from somewhere that is actually useful and not just a teaser. From our early testers, it seems we have that, but quite a few rough edges and small buglets still need to be sorted out.

DP: Besides a well-deserved vacation, what do you envision for yourself beyond Ardour 3?

PD: We have items on the to-do list for Ardour 4 and beyond already. Thinking that far ahead gives me a headache to be honest. My main concern right now is moving Ardour in a direction where I can make a reasonable (US) income and getting 3.0 out to the public.

DP: JACK also has developed well, and I understand the jackdmp project eventually will replace the current jackd. What improvements will be seen at the programmer's level and by the normal user?

PD: For the programmer, almost none whatsoever. Jackdmp is both ABI- and API-compatible with jackd, so you can compile JACK clients against either one and run them against the other. This is entirely by design—it's not an accident, and it will not change. For developers of JACK, jackdmp (in C++) is a much cleaner codebase than jackd, and this is one of the major motivations for switching to it in the future. JACK, by design, is rather complex software, but the jackd codebase (in C) has way too much hackery and not enough clear design to be a good base for us moving forward. Jackdmp's internal code design, apart from just support for multiple processors, is much more modular, much more object-oriented and basically easier to extend and even to comprehend.

For the user, jackdmp offers multiprocessor support for parallel audio processing configurations (which are actually rather uncommon), and in the future, it may offer ways for users to get all their processors utilized by JACK even if the audio processing configuration has no inherent parallelism. Other than that, we hope users will not see a difference in the basic functionality. That said, other areas evolving rapidly in the jackdmp codebase are ways to start, stop and otherwise control JACK, and this will be of great benefit to many desktop users once we release it.

DP: What are the most important aspects for programmers and users of the new JACK MIDI capabilities?

PD: For programmers, the main benefits are first, a way to send MIDI data between applications with sample-accurate timing, and next, a consistent API for both audio and MIDI. There is one effect that can be a bit of a complication—the consistent API means audio and MIDI data arrive in the same thread. This is a rather fundamental change from other systems where the audio and MIDI APIs are quite distinct and tend to lead to applications handling audio data in one thread and MIDI in another. It's an issue we're still working on in Ardour 3.0.

For users, the main benefits are hopefully just better ways to connect independent applications and get maximal sync between them. This can be tricky to get right at present, for reasons largely out of the user's (or programmer's) control.


Similis sum folio de quo ludunt venti.