Paul Davis: an Ardour for the Challenge
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.
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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Tips for Optimizing Linux Memory Usage
- Secure Desktops with Qubes: Introduction
- Working with Command Arguments
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Secure Desktops with Qubes: Installation
- Fancy Tricks for Changing Numeric Base
- CentOS 6.8 Released
- Linux Mint 18
- The Italian Army Switches to LibreOffice
- Petros Koutoupis' RapidDisk
Until recently, IBM’s Power Platform was looked upon as being the system that hosted IBM’s flavor of UNIX and proprietary operating system called IBM i. These servers often are found in medium-size businesses running ERP, CRM and financials for on-premise customers. By enabling the Power platform to run the Linux OS, IBM now has positioned Power to be the platform of choice for those already running Linux that are facing scalability issues, especially customers looking at analytics, big data or cloud computing.
￼Running Linux on IBM’s Power hardware offers some obvious benefits, including improved processing speed and memory bandwidth, inherent security, and simpler deployment and management. But if you look beyond the impressive architecture, you’ll also find an open ecosystem that has given rise to a strong, innovative community, as well as an inventory of system and network management applications that really help leverage the benefits offered by running Linux on Power.Get the Guide