Paul Davis: an Ardour for the Challenge
DP: What advice do you typically give to someone who wants to get into programming music and sound software libre?
PD: Please don't start a new project! Find some software that does something useful for you, or close to what you are thinking about, and consider improving it/changing it/redesigning it. Far too many new developers massively underestimate the work involved in creating a useful, final version of any audio/music software—I know I did, by an amount measured in years! There are a few exceptions. Rui Nuno Capela's QTractor Project is progressing at a pace that is embarrassing to me, and little tools like tuners and so forth can be quick to develop and finish. But please, no more MIDI trackers, MIDI sequencers and so on until you've done some work on the existing programs and have established beyond all reasonable doubt that they cannot be bent to your will.
DP: Do you have any general advice for users of music and sound software libre?
PD: No advice, only apologies for developers like myself using them as Guinea pigs and testing platforms. Oh, and be patient. Oh, and send money!
DP: What do you consider to be the greatest strength(s) and greatest weakness(es) of Linux audio?
PD: I believe that from a technical standpoint, Linux is still a far superior platform for audio than anything else out there. Not only does it have better performance for just about anything that matters, it also has a suite of development tools that make a developer's life much easier. Many OS X developers love XCode on that platform, which is great but locked into the Mac. And, where is valgrind when you need it? When I started working more intensely on the native OS X version of Ardour, I held OS X and Apple in very high esteem. Their user interface work has always been exceptional. Sadly, I have to admit that as I have gotten deeper into OS X as a developer, I have become less and less impressed. The things that are really great about Linux from a developer's perspective are just not there—most of all simplicity and transparency. It also helps that I helped design JACK, the audio I/O framework that most pro-audio and music apps on Linux use—I am working in a style and paradigm I can truly call my own (though I'd like to note that many other people have commented on its simplicity for developers and its power for users).
However, useful software for noncomputer-centric users means a lot of work for someone. And a lot of work implies a lot of time. In our culture, a lot of time generally means a lot of money, one way or another (inheritance, windfall or income). The Linux audio ecosystem has not yet found good ways of generating this money, and as a result, our software (my own and that of many Linux audio developers) lacks some of the things that can be found in proprietary software for Windows or OS X. I say that there is a direct relationship simply because of the time = money equation. If I could pay the right three people to work on Ardour, it's hard to imagine what we could not do. Ableton employs many, many more people than that and it shows in their software. Look at something incredibly basic like tempo-sync'ed LFOs in a plugin or softsynth. I don't know of any Linux audio software that does this, but it's been in proprietary software for at least five or six years.
So, we have a set of really, really excellent tools for users with a technical/computer-centric perspective on their work. We have not reached the same level of accomplishment in terms of providing tools for people who don't want to understand how computers work. And by comparison with a tool like GarageBand, we haven't even done very well at tools that hide the assumptions about how “professional” audio software is supposed to be used (GarageBand hides this very, very well, though at considerable cost to users who develop sophisticated needs rather rapidly).
DP: What else goes on in your life that you'd like readers to know about?
PD: Moving to Berlin to teach for a semester at the Technical University within a week of moving our son off to Los Angeles to go to film school has to be one of the highest stress things I've ever been involved in.
Dave Phillips is a professional musician and writer living in Findlay, Ohio. He's been using Linux since the mid-1990s and was one of the original founders of the Linux Audio Developers group. He is the author of The Book of Linux Music & Sound (No Starch Press, 2000) and has written many articles on Linux music and sound issues for various journals and on-line news sites. When he isn't playing with light and sound, he enjoys reading Latin literature, practicing t'ai chi, chasing shar-pei puppies and spending time with his beloved Ivy.
Similis sum folio de quo ludunt venti.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Paranoid Penguin - Building a Secure Squid Web Proxy, Part IV
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- SourceClear Open
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide