NINJAM is a collaborative musical jamming software system which has pioneered the concept of "virtual-time" jamming (as opposed to "real-time").

Pioneered? Pffffbtt. Rocket Network (later purchased by Avid to form DigiDelivery) was doing this very thing, in practice, as a business, back when Justin was still working on Winamp 2 (2000). Spare us the marketspeak please.

Yeah, also aside from ResRocket DRGN there were a few other network-jamming systems, such as the experimental network driver of Impulse Tracker. 216.254.25.199 05:02, 29 June 2007 (UTC)[reply]

I just did a little reading on Rocket Network, and it doesn't seem to be "jamming software" in the same way that NINJAM is. Of course, I've never used it, but from what I gathered, it's more of a trade back-and-forth virtual studio process. comparison on NINJAM forums, BBC article. I think it's safe to call NINJAM a pioneer... —Preceding unsigned comment added by Dkanaga (talk • contribs) 16:20, 2 September 2009 (UTC)[reply]

OK, moving this forward:

Introduction

NINJAM provides a non-realtime mechanism for exchanging audio data across the internet, with a synchronisation mechanism based on musical form.

Creating music naturally relies on players' ability to keep time with each other. Latency between players causes natural time keeping to be thrown awry. The internet does not provide a low-latency data exchange mechanism that can be used over global distances. In order to achieve some semblance of latency-free collaboration, a workaround is needed.

In NINJAM, this is achieved by delaying all received audio until it can be synchronised with other players. The delay is based on the musical form. This synchronisation means that each player hears the others in a session and can play along with them. NINJAM defines the form in terms of the "interval" - the number of beats to be recorded before synchronising with other players. For example, with an interval of 16, four bars of common time would be recorded from each player, then played back to all others.

Technical Background

Each player in a NINJAM session feeds audio data from their client to a server via a TCP/IP connection to a specific port (commonly in the range 2049 upwards, depending on the host).

The "client" here is only the component that the player uses to connect to a NINJAM server, encode and transmit their audio stream, receive and decode remote players' streams and handle the chat (IRC-like) session. Each player will also need some way of feeding audio information to the NINJAM client - either by using the client as a plugin in a DAW or by using the standalone version with a direct audio input.

Each client's data is synchronised against a distributed clock. This clocking is then used to distribute the data out to all the other clients so that they can play all the remote streams in sync. The server does little apart from manage connections, chat and data streaming.

Comparison with Alternatives

eJAMMING

synthtopia article.

Subscription service relying on low latency internet connections. NINJAM is not tied to a single supplier and does not rely on being local (in internet geography terms) to the people you want to jam with.

RocketPower

Articles

Subscription service relying on a central server. Appears to be "track at a time". NINJAM calls this "session mode" in the Reaper-tied client. Only currently offered on the Cockos server.

RiffLink

sonomawireworks article.

Appears to be another "track at a time" collaboration system like RocketPower.

Internet telephony

A pervasive but high-latency technology with no provision for synchronisation. Internet telephony requires some adaptation for usage for musical collaboration. (Anyone got any refs for its serious use? I see mentions of it as "urban lingo" and refs to Facebook...)

Overview of Usage

Clients and Client Setup Considerations

Common Considerations

All clients feed data at 0dB to the server, regardless of local monitoring levels. When setting up, set the NINJAM client "local" level to 0dB. "local" does not affect transmitted volume. The slider labelled "local" only affects what you hear locally, not what others hear. You must adjust your input level - before the NINJAM client in the signal path - to affect what remote players are hearing.

There is only so much headroom in an audio channel. Never peaking above 12dB and having a "loud" level around 18dB ensures space in the mix for others.

Reaper-tied VST effect

Probably the most commonly used option (based on number of posts on the NINJAM support forums) but requires that you use Reaper.

Open Source AU plugin

Derived from the Open Source Standalone version, works on Mac AU hosts. Similar considerations to Reaper-tied VST effect above.

Open Source Standalone clients

Standalone clients are available for Windows, Mac OS and Linux. As the Linux version works with JACK, it can have audio routed to it from any JACK client. On Windows, use with virtual audio sources is problematic as there is no comparatively easy routing mechanism. Hence it is more suited to real instruments, where it provides a simpler alternative to the complexity of running a DAW just to access NINJAM.

Talk:Ninjam