I used to be a wizard at Pro Tools — I knew most of the useful features and keyboard shortcuts, and could work very efficiently with it. Several years ago, I switched to Logic Pro (9, and then X), and it’s become my primary DAW. Unfortunately, while I can find my way around it, I’m still not as efficient at it as I once was with Pro Tools. That’s why I’m glad I found a great keyboard shortcut cheat sheet for Logic Pro X. I’m going to print it out and keep it next to my computer so I can start becoming a Logic Pro X wizard!
When working with serial digital audio interfaces on embedded devices, one comes across several different interface formats, such as I2S and TDM. These formats are all very similar — they use exactly the same lines for the same purposes, but have subtle differences in the alignment and phases of the signals on those lines. The best and most concise explanation of the differences between these formats is an application note (AN282) from Cirrus Logic. I refer to it occasionally when I need to refresh my memory of exactly which format I’m working with.
I was looking at some code for testing external memory devices recently, which motivated me to try to find some resources on how to properly test memory from software. I found a good article by Michael Barr (an expert author on embedded software topics) which recommends a test strategy and thorough set of tests, along with code examples.
My biggest takeaway from the article was, “… [T]he most common source of actual memory problems is the circuit board. Typical circuit board problems are problems with the wiring between the processor and memory device, missing memory chips, and improperly inserted memory chips.”
A friend of mine recently recommended an interview with producer/engineer Tchad Blake on Pensado’s Place. Tchad’s resume is long and diverse, but I know it best from the recent Black Keys records, which sound incredible. I found the interview interesting, and thought the following points to be especially noteworthy:
- There is a fair amount of discussion in the interview about Tchad’s transition to mixing primarily in the box, and using plug-ins extensively. I was glad to hear this, because I’m a big fan of working in the box, and think it gets far too bad of a reputation from audio engineering purists. It turns out that even world-class engineers use digital recording, plug-ins, and the in-the-box workflow to make world-class records!
- Tchad claims that he hasn’t used a bass amp in 20 years, preferring to record basses direct and tweak the sounds afterwards (usually in the box). As a bassist, I appreciate nice bass amps, but as an audio engineer, I definitely prefer to record bass direct.
- It’s interesting to hear all the different uses Tchad has for the SansAmp plugin. It goes far beyond coloring guitar sounds. To me, this reinforces the importance of experimenting and of not being afraid to use a tool for something other than its intended purpose.
I’m currently doing some recording with my band, and I was looking for some ideas on how to mic our drums. We decided to dedicate a recording session to drums alone, so I knew I would have more time and input channels than usual to devote to drums, and I wanted to make the most of that opportunity. I figured I’d want to close-mic the kick, snare, and toms, and put up some overheads, primarily for capturing cymbals and the overall stereo image of the kit. I decided to spend some time investigating overhead miking techniques to try to get the best overhead setup possible.
I found useful articles (with audio examples!) on RecordingHacks and on the Shure blog. The audio examples in both articles are excellent and do a great job illustrating the resulting sound of each technique. Here are my thoughts after listening to them:
- X-Y sounds very good, but results in a very narrow stereo image. I would probably decide against it for most pop/rock-type drums. It seems like it’d be best for jazz, and for songs that want more of an understated drum sound.
- Spaced pair results in a really nice, wide stereo image. It definitely seems like a great choice for rock drums. The high risk of phase issues suggests that this is a technique that requires a lot of attention to get right, but the results seem worth it.
- ORTF results in a somewhat narrower stereo image than spaced pair, but sounds very natural. It seems like a technique that can get very good results without too much setup hassle.
A friend of mine also suggested that I try the Glyn Johns method, but it sounds like an advanced enough technique that I’d probably save it for a later session, once I’ve had more drum recording experience.
I was looking for a good refresher on memory technologies (e.g. NAND vs. NOR flash) today, and I came across the following “mini-course” (a set of slides with audio narration, 76 minutes long) provided by Numonyx: http://techonline.com/electrical-engineers/education-training/courses/4000348/Fundamentals-of-Memory
A fair amount of the material presented may be review for those with a computer engineering or electrical engineering background, but I still found it useful and interesting. It also contains an interesting overview of some future memory technologies.
I first came across Conway’s Game of Life randomly a few years ago on Wikipedia. I had heard of cellular automata before then, but hadn’t really understood what they were. Reading through the article, I was fascinated by how a collection of extremely simple “cells” (each having a binary state, “alive” or “dead”), when allowed to interact in an environment with extremely simple rules, can come to exhibit extremely complex behavior, even giving rise to “multicellular organisms”. Students of complex systems will find this phenomenon quite familiar, but for me at the time, it was new and mind-expanding.
Having worked on networked systems for the past few years, I can’t help but think Conway’s Game of Life is a great metaphor for how they behave. Each device in the system may be relatively simple, and its design and behavior relatively well understood. However, when allowed to interact with one another, such devices may exhibit behavior that’s very difficult to anticipate from the designs of the individual devices (and sometimes just plain baffling). It’s important to keep this in mind when estimating the workload and complexity of a project involving any sort of networking functionality.
I’m currently borrowing “Effective TCP/IP Programming: 44 Tips to Improve Your Network Programs” by Jon C. Snader (Amazon link) from a colleague. It’s got some really great advice on building robust and efficient networking application code, especially on top of TCP/IP and UDP/IP. I’ll probably be picking up my own copy soon.