Unplugged

My wife and I are getting away next week to celebrate our 5 year wedding anniversary.  I’m going to do my best to unplug from all things work so that includes this blog.  Posts will resume when we return the week of March 2nd.  See you then!

Super Bowl Profile from ATK

In honor of the Super Bowl, here’s a really cool profile on the 2007 event from the PA vendor, ATK Audiotek.  If you’re like me, it’s an interesting read.

Digital Piano

I’ve mentioned briefly our new piano setup but now that I have a great sample to share, I thought I’d go into a bit more depth on what we’re doing.

The shell is made by Slam Grand Pianos.  It is a 7ft 4″ model based off of the Yamaha C7 shape.  Gary Raffanelli at Slam Grand did amazing craftsmanship and was so easy to work with.  His company builds piano shells for practically everyone who’s anybody – TV shows, touring, casinos, etc.

Inside the shell is a Yamaha CP33 Stage Piano that we use as a MIDI controller.  We chose this board based on the recommendation of some of our keys players for its realistic feel.  Even though we don’t use the internal sounds in the CP33 as a part of this setup, its great to know that its built in piano tones are still pretty strong and a good option to have available in a pinch.  But for realistic feel when playing, the CP33 is pretty awesome.  The Graded Hammer Effect action gives all keys an authentic resistance that increases from the top register to the lower – just as on an actual acoustic piano. Which means that you can naturally pound out thunderous low notes with your left hand and let the fingers on your right dance and fly with the high notes.

Then the electronics are based around a Muse Research Receptor and Synthogy’s Ivory.  When we were planning to go the digital grand route, I felt strongly that a sampled library with a few choices of pianos and tones would be the most flexible option and a great investment rather than just using a digital stage piano.  The best one we’d heard was a Yamaha CP250 but even then, it was missing realism to me.  It still sounded digital.

The challenge was how to execute a software library in a consistent, reliable, and simple package on stage.  No one was very excited about relying on a tradition computer setup – even if it were a Mac based solution.  Enter the Receptor.  The RECEPTOR was designed to do just one thing: run virtual instruments and effects in a live context.  It utilizes a highly optimized, super-efficient OS and kernel that runs on a dedicated 64-bit processor-based hardware to make VST plug ins available without needing ProTools or Logic and a traditional computer setup.  The best part is that you can operate Receptor from the front panel (which is what we do on a week to week basis to load from our patch library), connect a monitor, mouse, and keyboard to the back of the unit and see the plug-in GUIs, or remote control the unit via Ethernet (allowing the ability to change settings from a computer at FOH during rehearsal).

Synthogy Ivory sounds great. The creators sampled three different pianos – Yamaha C7 Grand, Steinway D Concert Grand, and Bosendorfer 290 Imperial Grand. Each key is sampled at 10 different velocities with several pages of customization options for how the piano responds, dynamic range, effects, tuning, how it is mic’d, etc.

Kudos to my friends at Willow Creek for putting us on to the Receptor & Ivory.  The result is a natural sounding solution that sounds like the real thing. Now we are able to use the grand on our stage almost every week.  Its become a staple just like our drum kit, which adds a lot to the look of the band.  Best of all, there’s no feedback, piano tuners, or inconsistent results.  The piano always sounds great and can be placed in the mix in ways that were never achievable with our acoustic one.  Most importantly, this package has been rock-solid reliable.  I highly recommend Slam Grand, Receptor, and Ivory.

Below is a video from a prelude a couple weeks ago with a traditional jazz quartet. Check it out to see for yourself…

SMPTE Part 1

Christmas 2008 was my first experience diving into SMPTE, MTC, and VTR decks so that we could sync our primary Beta deck with ProTools for audio track playback.  In order to start this discussion, I thought it would be a good idea to start out with SMPTE 101.  Brent Hoover wrote a great overview over at the study hall on ProSoundWeb.  Below is a summary of his thoughts…

What is Timecode? 
Timecode is simply a way of recording a “time” along with either a visual or audio event. This allows you to say, “The beginning of the song is at 0 and the cymbal crash happened at 2 minutes and 53 seconds.” The information is then stored along with the audio or video medium so that, as it is moved from device to device, the time information stays the same.

The most commonly used timecode format was developed by the Society of Motion Picture and Television Engineers. Referred to as SMPTE (pronounced Simp-Tee), it was originally developed to synchronize sound for film but has since been adapted for video as well as audio-only use.

The other commonly used timecode format is Midi Time Code (MTC), which was developed by Chris Meyer and Evan Brooks for Digidesign.

How does Synchronization work? 
Imagine that you and a friend have the only two watches in the world, so that you have no time reference other than your own watches. You need to meet at an exact time later that day. No watch is exactly accurate – maybe yours is a bit slow and your friend’s is a bit fast. Over the day the result is that there is a 10-second difference between your two watches. While it may be okay with your friend that you’re 10 seconds late because he likes you, it would be very bad for a cymbal crash. In audio, even delays of a fraction of a second with doubled vocals can be noticeable.

The next day, in order to circumvent the 10-second time difference, you and your friend work out a system. You pick one person as the Master and one person as the Slave (it’s that kind of friendship). The Master calls the Slave on his cell phone and tells him what time it is every few seconds, and the Slave resets his watch to match the Master’s. While this system may be an annoying prospect for human beings, it works quite well for machines. Similarly, in every timecode set-up you must determine which machine is the master (there can be only one) and which are the slaves. Usually the constraints of the machine will define who is master and who is slave. 

How would I use Timecode? 
Sync-to-Video - The simplest video sync scenario works much like this: a VHS tape has LTC on one of its audio tracks (it is the Master). The device to be synced (the Slave) reads that timecode and chases it. The tricky part is determining which type of SMPTE frame rate to use.

When using SMPTE at 30 frames-per-second (fps), one second equals one second. Unfortunately, NTSC color video does not run at 30fps — it runs at 29.97fps. Why in blazes does it do that, you ask? Well, let’s just say that video, like life, was simpler when it was in black-and-white. But when color was introduced, they decided to cram that little bit of color information in the space left by .03 frames.

At 29.97fps, a second of material is no longer a second, but just a hair longer. While a few hairs may not matter to you and me, they matter a lot to people in television who make their living selling seconds, so these people came up with a solution called “drop-frame”. This means a few frames are dropped so that SMPTE time matches with real time.

So we have SMPTE at rates of 30fps, 29.97 “drop” and 29.97 “non-drop”. All that really matters on a basic level is that you need a tool that can handle all these different frame rates, and you must know exactly what frame rate the video you are syncing with is using.

In the next post on SMPTE, I’ll go over our setup and implementation, along with some learnings from an intense production process.

All These Things That I Have Done