Further Notes on Recording "Talkin bout the Weather"
My article in the March 2005 issue of Linux Journal, "Introducing Ardour", left out some details regarding the production of "Talkin' 'Bout The Weather". That's the song I composed as an example for my article. These notes are intended to fill out that article, so please refer to it if you don't understand what I'm talking about here.
In addition to the equipment listed in the article, I used a Shure SM58 microphone for recording my vocal and harmonical parts. The strummed guitar was a cheap Alvarez electroacoustic. I didn't care for its sound when recorded directly--that is, plugged into the mixer--so I recorded it instead with a Yamaha MZ160s mic. The Tascam TM-D1000 mixer was a godsend. Thanks to its digital I/O, I recorded all acoustic parts from the mixer into the digital ports of the Delta-66 audio interface. The final stereo mix was routed to the Yamaha DMP11 digital mixer and out through a QCS power amplifier to a pair of good near-field studio monitor speakers. As expected, the recorded sound was clean and clear.
I wrote the simple bass and drum parts in Voyetra's Sequencer Plus Gold (Seq+), a MIDI software sequencer dating from the late 1980s. Its written for MS-DOS and without graphics other than the extended ASCII character set. So why would I want to use such software in my otherwise modern Linux audio arsenal? Well, I've used Seq+ for most of my MIDI sequencing for almost 20 years, so I know the program well and can work with it rapidly. Of course, I'm not running it under MS-DOS anymore, I'm running it under DOSemu, a DOS environment emulator for Linux. Thanks to the care and talents of the DOSemu developers, the emulator supports the basic SoundBlaster audio services, including MIDI I/O, and runs well with the emulator. Seq+ was a highly successful commercial product into the middle 1990s, but eventually production and support were discontinued. Recently Voyetra decided to give away Seq+ as freeware, not software libre. Actually, the company is giving away almost all of their MS-DOS MIDI software, without support, but even the proprietary MIDI interface drivers are now giveaways.
As I wrote in my article, I wrote some of the songs tracks originally as MIDI tracks and later converted them to WAV format audio files. Here's the magic formula I used with TiMidity:
timidity -Ow filename.mid -o new-filename.wav
Actually I used -OwM to create mono tracks for everything except the drums, for no other reason than I thought the drums would sound better in stereo. I did things this way because I could quickly reconfigure TiMidity for different sets of soundfonts, giving me more flexibility with my sound combinations. Here are the contents of my ~/timidity.cfg file:
soundfont /home/dlphilp/soundfonts/FluidR3_20GM.sf2 # soundfont /home/dlphilp/soundfonts/PC51f.sf2 # soundfont /home/dlphilp/soundfonts/8mbgmsfx.sf2 # soundfont /home/dlphilp/soundfonts/GS_Roland_Sound_Set_16_bit_Bank.sf2
Thus, I could select from four different realizations of the same MIDI file, making it an easy matter to re-orchestrate my recording. Each MIDI file included the same tempo track, guaranteeing accurately coordinated playback. However, to offset the rigidity of untreated MIDI playback, I often write an asymmetrical tempo track with a series of looping values, in 16th notes or smaller, moving back and forth between t+2 and t-2 to create an underlying gentle instability in the feel of the tempo.
I employed the Snd soundfile editor for a variety of utility tasks, such as fades, normalization and patching together fixes for poorly recorded segments. For example, the rhythm guitar part was recorded badly, but instead of replaying the part, I removed the affected regions--Ardour has excellent region definition tools--and used Snd to replace seamlessly the bad parts with sections copied from elsewhere in the track. Again, Ardour made it simple to re-insert the corrected region. As I learned more about Ardour, I discovered that I didn't need to rely upon Snd for my utility edits. However, my version of the editor is customized heavily for my own use, and you already may have noticed I have quite a retro streak when it comes to software I know and love.
The LADSPA plugins were another blessing. I used Steve Harris's plate reverb for the vocal and harmonica parts. The MIDI guitar patch was treated by Tom Szilagyi's TAP Equalizer, and the entire mix was processed by the SC4 compressor, once again from Steve Harris. Plugins are saved in their current state when an Ardour session is saved, and I also could save my parameter settings as presets for use in other sessions.
By the way, the vocal was a first take. I'd practiced the song for quite a while before recording it. However, the harmonica part took some practice: I hadn't really played blues harp for many years, so I was conservative about its part in the sound. Fortunately, my initial efforts weren't so bad, so I practiced over the recorded tracks for a while and came up with the part heard in the released mix.
Mixing and balancing only seven tracks may seem to be a straightforward task, but with Ardour's flexibility it easily was the lengthiest part of the process. Auditioning the various combinations of tracks took time, as did testing and retesting them with the LADSPA plugins. Fortunately, I was having a lot of fun, and it was a pleasure to hear and consider the possible arrangements. Ardour makes it easy to mute and solo tracks, individually or in user-defined groups. I balanced my bass and drum parts first and then added the other tracks one by one, auditioning until I was satisfied with the overall mix.
Incidentally, I wrote the melody and most of the lyrics more than a year ago. The dominant seventh riff was something ultimately borrowed from years of playing blues guitar. I debated whether I should add a vocal bridge, but I couldn't come up with anything that satisfied me. Finally, the pressure of writing the Ardour article forced me to come up with the harmonica break, a happy circumstance.
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!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Rogue Wave Software's Zend Server
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