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.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Designing Electronics with Linux
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Dynamic DNS—an Object Lesson in Problem Solving
- New Products
- Using Salt Stack and Vagrant for Drupal Development
- Validate an E-Mail Address with PHP, the Right Way
- Build a Skype Server for Your Home Phone System
- A Topic for Discussion - Open Source Feature-Richness?
- Tech Tip: Really Simple HTTP Server with Python
- Why Python?
- Not free anymore
2 hours 5 min ago
5 hours 52 min ago
- Reply to comment | Linux Journal
6 hours 22 sec ago
- Understanding the Linux Kernel
8 hours 15 min ago
10 hours 44 min ago
- Kernel Problem
20 hours 47 min ago
- BASH script to log IPs on public web server
1 day 1 hour ago
1 day 4 hours ago
- Reply to comment | Linux Journal
1 day 5 hours ago
- All the articles you talked
1 day 7 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?