PLEASE NOTE: This article has been archived. It first appeared on ProRec.com in August 2007, contributed by then Editor Ron Guensche. We will not be making any updates to the article. Please visit the home page for our latest content. Thank you!
I’ve spent most of the last decade involved in remote collaboration as a tech support engineer for ednet, whose primary business model is real-time, remote audio collaboration via ISDN & IP for the advertising, post / ADR, and music markets. It’s a high-end, niche business that works very well for studios needing what we like to call “CD-quality phone calls”. During this time, my project studio has also needed to collaborate with other studios over long distances. Typically, I address this by primitive (fedexing or mailing CDs/ DVDs), or mid-tech (emailing .mp3s, FTP) means.
Unfortunately, these solutions are not suited to a real-time collaborative experience. Mail and Fedex obviously won’t work. ISDN and IP come close, but coding and transmission delays are greater than acceptable for two studios playing music together live. MPEG layer 3 coding delays on dedicated hardware can be up to a third of a second, and even the fastest compression algorithm I have experience with (APTx–it boasts about a 2ms encode time), is subject to 25 to 80 ms transmission delay depending on how fast it gets through the IP or ISDN network…not quite good enough for two studios to play together tightly. Add to this minimal install costs of over $5000 per side for the system, it’s not practical for the average musician.
Enter NINJAM (wiki: NINJAM). While the program has been around for a couple years, it’s relatively unknown outside its modest user-base. Brought to you by Cockos, the same folks responsible for Reaper, NINJAM is a pseudo-real-time jamming environment. Instead of attempting to minimize coding and transmission delays, the program increases them to user-defined, musically useful values—that’s right, measures, expressed in meter (bpi) and tempo (bpm).
So how does this work? The simplest way to describe it is that everybody plays one measure behind everybody else. Taking a simple two-person jam, a drummer plays a drum kit to a click for bar one. The program streams, via a NINJAM server, bar one of the drums to a bassist. The bassist returns a bassline to the drummer by playing to bar one of drums. The drummer will hear this bass line while playing bar 2. The bassist will hear and play to the second bar of drums as the drummer is playing the third bar of drums to the bassist’s second bar of bass and so forth.
Breaking the Laws of Physics
It’s a temporal head melter (especially considering sessions of 6 players are supported on Cockos’ servers), but in practice, it’s easier to use than to describe. Once in the groove of a NINJAM session, it’s easy to forget the details of how the program works, and convince yourself you’re breaking the laws of physics. On my first foray into the program I was playing bass in California with a drummer in Paris and a guitarist in (I think) Italy. After a while, we were able to land some dynamic punches and unison melody lines. Very cool
The behind-the-bar arrangement of time inherent to NINJAM presents an issue with flubs snowballing out of control…one person messes up, the next hears the mistake, screws up, which in turn which throws off the first player again. If everybody locks into the click track though, it’s not a big deal. This delayed-time arrangement also makes dramatic chorus / verse changes difficult, and makes voice communication awkward to impossible. On the other hand, it works surprisingly well for slowly changing compositions and space-rock / drone jams, and is a natural for any genre using steady, programmed drums. To provide instantaneous communication between players, NINJAM includes a real-time chat feature.
NINJAM uses IP as its transport medium, so it requires your computer to be connected to the internet. Understandably, many engineers are leery of this; for them, I’d recommend using a non-critical machine for peace of mind. NINJAM is surprisingly processor efficient, so a modest machine should be fine.
The OGG Vorbis audio codec used in NINJAM sounds very good, and allows the program to work with most consumer-level high speed internet connections. Users can reconstruct sessions, via an option within the software to save the jam in real-time—with local material either compressed or uncompressed, and far end material in the OGG Vorbis format. Within Reaper, these session files can be re-assembled with ease.
NINJAM is a multi-platform, server / client software package, and is available for OSX, Windows (from 98 to XP 32), and Linux, and as a plug-in for Reaper. The Reaper plug, ReNINJAM, is the slickest way to go as it allows you to interface directly from a multi-track project, but the standalone application is a graceful option for the less technically inclined.
Cockos host a “JamFarm” on their site by installing the client you can join existing Jams and get a feel for the program. I found it helpful to enter jams “listen-only” (by muting the send to the jam) to learn the program’s quirks and community etiquette. If you want to connect with specific folks privately, you’ll want to set up your own NINJAM server. Instructions for this are included on the download page, and it’s a fairly simple process.
Oh, forgot to mention the best part. It’s free.
Practical Application Notes
Most of my experience with NINJAM was in preparation for an ambitious session involving over 40 people, players and engineers, on both US coasts. Other IP methods to connect bi-coastally were tested, but failed due to firewall and / or economic issues, and none tested allowed for feedback from the remote side. It was a last-ditch effort that NINJAM was even used — the band leader was dead-set against using a click if it could be avoided. Respectable under ‘normal’ circumstances, but this was anything but.
The project was an all-live session, consisting of a trio (drums, bass, guitar/vox) accompanied by a choir of around 25 in San Francisco, and a second choir of 10 in New York. SFSU hosted the CA players in a theater and tracked 16 channels to a 2” 24 track system downstairs in the basement; NY players performed in a live/work loft in NYC.
With SF rolling, a cue mix went to NY via NINJAM (on a PC with an RME Hammerfall card). NY returned a stereo pair (NINJAM on a mac / MOTU Traveler combo), and the return from NY was tracked in real-time to 2″. Once situated, we tracked three takes without a hitch…as the bassist on the session, it was very inspiring to hear the distant choir come in from nowhere while playing. I have to add, with the myriad problems computers are capable of dishing out, it was refreshing that both studios were able to download the program, install it on their respective machines, and be working together in about 5 minutes.
The keys to making this work were:
- Feeding the instrumentalists a strong click. To keep a more natural feel, only the trio heard this.
- Sending a mix-minus to NINJAM. Feeding the output of NINJAM back to its input, will drive the remote talent absolutely bonkers.
- We had a single-progression song, and set the measure length (BPI parameter in NINJAM) to span the longest phrase in the song. For us, that meant 20 — 4 bars of 5/4.
While the intent is to transfer the 2″ to Nuendo and line up the uncompressed tracks from NY, playback from 2″ sounded excellent, with no complaints of coding artifacts on the NINJAM channels.
