Projects
Audiomatch.net
Lead Programmer: Neeraj Kumar
Databases and Front End: Roy Kim
March 2004 - Present
With a proliferation of music artists working on blending various styles
of music, the use of traditional genres to describe an artist's creative
output is becoming increasingly less useful. In addition, people have
varied tastes and often like music in widely different genres, and it is
often the case that other people similarly like the same collection of
artists. Due to our strong interests in music, we decided to create a
system that could recommend artists that would match with a listener's
tastes. Thus, audiomatch.net was born.
The basic idea is simple: users install a small plugin to their music
player which sends metadata about their currently playing song to our
servers. As a first level of service, users can access this history of
played songs and look at various statistics about their listening
preferences. In addition, they can generate dynamic text or images based
on their current song (e.g. for displaying on their webpages or AIM
profiles, etc.).
However, the more interesting use of the data comes from a backend
analyzer (written entirely by me), which looks at all the data and automatically
determines which artists are similar to each other based on a few
different techniques. This backend has been written with several
implementation issues in mind. Since we do not have the resources to
store all our data in memory at one time and do the processing on it,
the program has been written to process manageable chunks of data at a
time (in terms of both memory and execution time) and combine the
results together once each segment completes. Another major portion of
the program deals with incorrect data (of which there is a lot, since we
use ID3Tags from music, which are frequently incorrectly labelled).
The output from this backend program is then stored in a database which
the frontend uses to display personalized suggestions for each user.
In the future, we are looking forward to adding many additional
features, a few of which are listed below:
- Automatic retagging of files with correct ID3Tags
- Forums and other features to facilitate discussion about music
- Friends lists--to see what your friends are listening to. These are
generated in two different ways:
- Manually, by choosing which users to add to your friends list
- Automatically, by finding users with a similar taste in music. This
method will allow users to discover other people with common tastes.
Compose-By-Chords Interactive Computer Music System
Fall 2004
As an avid clarinet player and listener of a variety of different styles
of music, I have naturally been drawn towards the third area of music:
composition. Combining my love for music with my fascination with
computer science, I worked on an interactive computer music system that
would allow people to create music on-the-fly by simply playing chords
that interested them. Similar in concept to the idea of "tone-poems"
that guided the work of many romantic composers, this system believes
that the important (i.e. musical and emotional) aspects of a piece of a
music are largely guided by the interplay of different chords. However,
to allow the composer to control other aspects of his creation, various
high-level concepts have to be somehow translated into lower-level
implementation details--a challenging problem.
My approach was to decide on a list of high-level aspects of music to
allow control of through the use of a MIDI-keyboard and sliders, and
then route these controls into a computer program which would generate
music according to these parameters. I used the graphical programming
language Max/MSP, created Cycling '74 Studios, which is the de-facto
stanard for these kind of applications.
First and foremost on my list is the ability for the composer to play chords on the
keyboard which form the basis of the music that the computer
creates. This list of chords is stored in a database for use later
in the piece (thus utilizing the well-known elements of repetition and
theme-and-variations). These chords are not only played in various
inversions and octaves, but also determine the pitches for various
arpeggiators and melodic generators.
To provide structure to the piece, a number of sliders are used for
different purposes:
- The most important slider is used for controlling the overall
"energy" of the piece. This controls the volume (most obviously), but
also elements such as the tempo of the piece. Exceeding certain
thresholds will also cut the song into "overdrive mode" to increase the
excitement of the piece.
- The next slider controls the "broadness" of the piece. This refers
to the number of instruments playing simultaneously, the level of
polyphony (number of independent musical lines playing), the range of
the instruments playing (i.e. number of octaves), etc. A piece with a
narrow broadness value will sound constricted or "simple" while one with
a high value will sound much more frenetic or complex.
- The counterpart to the "broadness" dial (which controls mostly
melodic elements) is the "rhythmic excitement" dial, which controls the
level of complexity and dominance of the rhythm aspects of the music.
Thus, as this dial is increased, the number of percussion instruments
increases, and the rhythms exhibited in the piece (including the melodic
lines) become more complex and involved. For example, syncopation
(accenting off-beats) and hemiola (overlapping non-congruent rhythms)
effects are more evident at higher values of the rhythm dial.
Based on these controls, the computer generates all the music that is
played. It decides on the exact number and the specific instruments
used, the rhythms for the chords, arpeggios and melodies, and all other
physical aspects of the played music. The instruments are chosen from a
pre-defined bank of midi, recorded, and other instruments. Obviously, a
large portion of this program is guided by stochastic choices, which try
to emulate realistic playing by frequently using previous material, with
an obvious bias towards more recently played motifs.
Screenshots (Click for full-size images):

Main Driver
Each subsytem is color coded for easy visual inspection of the composition of the entire system. Dark red is reset, light blue are inputs, yellow is the timing subsystem, light red is the arpeggiator, green is the chord generator, dark blue is rhythm section, cream is a monitoring system for the current selection of instruments, purple is the broadness subsystem, and orange is the energy subsystem |

Rhythm Generator
This is the subsystem which decides whether or not to repeat a previous set of rhythms or generate a new set. Light blue are inputs, green is the dispatcher which makes the decision, red is the history rhythm chooser, purple is the new rhythm generator, and yellow is the output |

Broadness Subsystem
This takes broadness values and decides the number and range of instruments of each type to have. Ligh blue are inputs, purple is the start of the decision process, where we decide the total number and range of instruments, green then decides the number of rhythm instruments, pink the chord instruments, and yellow the melody and arpeggio instruments |

Arpeggiator
This system is responsible for generating continuous arpeggios. Blue initiates the arpeggiator and sets the space from which to choose notes, red decides whether to ascend or descend, and green compute the actual values and performs error-checking |

Chord Generator
This simple component chooses the length of chord to play and sends the notes of the chord to the player component. |

Play Instrument
This component is what all the different sections eventually lead to because it is responsible for actually generating the right sound given an instrument, a pitch, duration, and other play parameters. The blue portion does routing and also plays synthesized notes (i.e. using Additive/Subtractive Synthesis, Frequency Modulation, etc.), the green portion plays MIDI percussion, and the red portion plays MIDI instruments |
ChromeSpeed 4455
Developed By Fusion Paradigm Studios
Lead Programmers: Neeraj Kumar and Anil Chawla
Graphics and Music: Sanin Rahman
Level Design: David Sharpe and Sanin Rahman
September-December 2003
ChromeSpeed is a networked, multiplayer vehicular
deathmatch game developed in under 4 months by Fusion Paradigm Studios.
Players join a server and battle it out in an urban environment, flying
one of two very different aircraft. With intuitive controls, fast
speeds, and exciting gameplay, ChromeSpeed delivers a solid gaming
experience for those looking for a quick, arcade-style game without
requiring a long time-committment.
Features:
- Networked multiplayer gameplay
- Choose from two different ships:
- The fast but weak Shark
- The slower but stronger Ray
- Urban map with lots of buildings to dodge through for an exciting
game
- Fire guided or unguided missiles to destroy your opponents.
- When firing guided missiles, enjoy your opponent's annihilation
courtesy of the MissileCam.
- Missile alerts warn you on incoming missiles
- Choose between 4 different voicepacks with over 50 sounds each to
taunt your enemies before (and after) killing them
- Featuring original music written and performed by Sanin Rahman
- Listen to your own music if you prefer, using the open source ogg
vorbis standard.
- Fully customizable controls
Screenshots (Click for full-size images):
Video:
Clarinet Music Arrangements and Synchronized Video for Surround Sounds Concerts
Fall 2002, Fall 2003
The Georgia Tech Marching Band has a long tradition of playing popular
music for sold-out crowds at Tech's Bobby Dodd Stadium and at football
stadiums across the country. However, in an effort to show its musical
capabilities, a series of concerts entitled "Surround Sounds" was
started in the fall of 2002, to be performed in a concert venue.
For this concert, each instrument group in
the band is allowed a few minutes to play some music of their own
choosing, after which the entire band reunites to play part of their
halftime show. The "surround" element comes from the fact that each
instrument is setup in a different portion of the auditorium so as to
quickly move from one group to the next without any lag time for new
setups.
For the inaugural Surround Sounds concert in 2002, the clarinet section
decided to present a medley of music we all loved in our childhoods:
that from the "Super Mario Brothers" video game series. To add more
excitement, we also decided to create a synchronized video that would
show clips from the appropriate game when we played that music. I was
responsible for arranging large parts of the music for clarinets, as
well as entirely creating the synchronized video. I also created a
percussion track that we played along to, so as to not lose our
synchronization with the video. The list of different pieces we played
is as follows (links point to mp3 version of midi output with oscillators+percussion):
The synchronized audio+video is available in compressed MS-Video format here (32 MB).
Due to the resounding success of that concert, the clarinets were under
a lot of pressure to come up with something even more exciting for our
second Surround Sounds performance in 2003. We again reached into our
pasts and decided to play music from children's shows we used to watch
when we were kids. We finally agreed on the following list of musics (links point to mp3 versions of midi output with clarinet+percussion):
This time, instead of merely showing clips from the tv shows, we also
recorded footage of ourselves and composited it with show footage (with
the most generous help and expertise of Mr. Jim Grant), and syncing this
entire footage with the concert. Even more than before, I was
responsible for the arrangements of almost all the pieces (with the
exception of Sesame Street), and I also orchestrated drum parts for all
the pieces to accompany us during the concert. Yet again, the concert
was a great success, with the clarinets receiving many praises from the
band directors and the audience members.