Résumé

Michael Eisel
PRESENT ADDRESS
PERMANENT ADDRESS
314 Hellman Way
4820 East Vassar LN
Los Angeles, CA 90007
Denver, CO 80222
(303) 868-6859
(303) 758-6859
michael.eisel@gmail.com
EDUCATION
University of Southern California, Los Angeles, CA
Pursuing a Bachelor’s of Science, Computer Science, 2014
Minor in Applied Computer Security
WORK EXPERIENCE
Counselor
Camp Dudley
Summer 2008
Westport, NY
Supervised boys aged 11-12, 24/7.
IT Administrator
Kent Denver
Summer 2009
Denver, CO
Worked on a team to repair and maintain the school’s computers.
iPhone Developer
Calle Soccer
Summer 2010
Denver, CO
Developed an iPhone app for the Soccer company Calle.
Fundraiser
University of Southern California
Fall 2010
Los Angeles, CA
Raised funds for USC through their alumni network.
IT Consultant
Self-employed
Summer 2007-Present
Denver, CO
Provide advice and computer repair for independent clients.
COMPUTER SKILLS
Years of work in IT, fixing and maintaining computers.
Mastery of C, C++, Java, Visual Basic, TI-89 BASIC, and LATEX.
HONORS AND AWARDS
Citiation for Excellence in AP Computer Science A
Citiation for Excellence in AP Computer Science AB
EXTRACURRICULAR ACTIVITIES
Association for Computing Machinery
Mobile App Hackathon: I worked on a team of four to create an Android app that allows parents of
mentally-disabled children to monitor their child’s location.
Surf Club

---

Proposal 1: Optimized Song Searching
The program would use ¿,¡,¡=, ¿=, =, OR, ! (not), and as operators. The quotes operators would
indicate that order matters for the user. For example, Lady Gaga would return only results with
Lady Gaga, and not Gaga Lady. The DJ would not necessarily type in all of the ID3 tag they want
to search through, and the searches would be case insensitive and could ignore accents. For example,
art: eminem would be enough to indicate they want to search artists for Eminem, and BP:¿80 would
indicate the BPM should be greater than 80. Operators like ’¡’ would be applicable to anything with
an integer value, i.e. the length of the song in seconds or the number of times it has been played.
The ID3 tags searched include Title, Artist, Album, Genre, and Composer. Results returned would
be prioritized by that exact order: a title match would be placed above a genre match. Results
could be narrowed down by their BPM, key, data created, play count, song length, and star rating.
The user would also be able to add their own custom ID3 tag searches, specifying the keyword they
would type in and what ID3 tag it would correspond to. I am well-read on the Full-Text-Search
3 and 4 standards, so implementing either wouldn’t be particularly hard. This project could even
include both implementations, with heuristics determining whether 3, which requires less space, or
4, which requires less computations, would be better suited for each execution.
The second component of library searching addresses the fact that a lot of DJ’s at parties will get
requests for some new song they don’t have. The following improvements would allow a DJ to quickly
get a song off iTunes, Hype Machine, MediaFire, or some other music search engine. After clicking
on ”Search...”, a dropdown would appear below, allowing the user to specify if they want to do a web
search. If they don’t specify anything, it would search the computer’s library as usual. Otherwise,
it would pull up a list of results from a set of sites the user picked and which Google’s search engine
or the site’s own search engine would search through and prioritize. The program would streamline
the downloading process by giving them a ”Download” button, which would download the song to
a specified folder and automatically add it to the music library, even gathering information about
the song as it downloaded. If legality is an issue, a pop-up box could appear upon downloading, or
as a one-time thing, having the DJ acknowledge that the music downloading they are doing is legal.
Timeline
May 14th- School ends, the summer has started!
May 20th- The grammar and operators have been formalized.
June 6th- The library search function is finished.
June 28th- GUI changes finished.
July 14th- Web searching finished.
July 28th- Web searching GUI finished.
August 14th- Documentation and debugging finished up, back to school!
Proposal 2: Session Recording and Exporting
The starting attributes of the volume levels, the fader position, the tracks queued, the BPM, whether
the flanger is on or not, etc., would be stored. Each time one of them was changed, the program
could record what exactly it was changed to and when. Then, the program could save the exact mix
as a data file, as well as show which tracks were played. This would be much more space efficient
than storing a full mp3 or wav file and would require less processing power. At any point in time, a
mix could be exported to the file format of the user’s choice. If a track is not being played, or if it
is silent, data will not be recorded. The recording feature could be toggled in much the same way it
currently is, except the audio file would be exported only after the computer reads through the list
of changes during the set. Also, when one tries to close out of the program it would prompt them,
asking if they’d like to export the set and/or the list of songs used. The list would be exported as a
PLS file. The set can be exported and reopened using its own specific filetype, designating that it is
the set of changes to the mix. Playback and exportation of the audio file would involve all relevant
settings to each audio track and then adding them on top of each other, in much the same way that
a mix is played out as it created. Underneath iTunes in the menu on the bottom-left hand side of
the program, I would put an entry called Histories. It would contain a list of previous sets, and if
one double clicks on each set, a list of tracks played. These tracks would be draggable, usable, etc.,
just like tracks from the Library section.

---

Additional areas to explore-
Could the DJ go back and edit mixes? I know I, for one, find it frustrating when I mess something
up on minute 49 of an hour mix and want to redo the whole thing.
Space requirements:
The number of attributes would no doubt be less than 256. As a result, each attribute could be
expressed with 8 bits. The time at which the song is played could be represented by a sample.
Capping mixes at a reasonable 4 hours, and assuming the track is sampled at 48 kHz, you would
have a maximum sample of 691,200,000, which is expressible in 30 bits. Let’s say I’m using my MIDI
controller, which has values ranging between 0 and 127 (7 bits) for each component of the program.
These properties could be expressed by an int and two chars internally: 48 bits per adjustment.
Moving the fader across, or bringing a volume level from 100
Timeline
May 14th- School ends, the summer has started!
May 21st- Standards for storing the files are finished.
June 6th- Storage methods for simple parameters, i.e. crossfading, are finished.
June 28th- Storage methods for complex parameters, such as vinyl control, are finished.
July 14th- Playlist exportation and track listing capabilities are finished.
August 1st- GUI implementations are finished.
August 14th- Documentation and debugging finished up, back to school!
How long have you used Mixxx and for what?
I have used Mixxx for the past few days, testing a few hours per day, which inevitably ends in me
messing with the Flanger knobs.
Why I am the best person for this project
What sets me apart is my experience both as a programmer and as a DJ. From years of working
with digital mixing applications, I have come to appreciate the huge functionality that even small
changes in a program can produce. I understand what a DJ is looking for in a mixing program,
and how by streamlining logistics, e.g. beatmatching, it gives the DJ big windows in their set to
experiment and add their own touch. As a programmer, I am constantly analyzing everything from
the user’s perspective to the low level bottlenecks. My experience working with my TI-89’s 256KB
of RAM has made me very conscientious of size and space complexities, and I am not afraid to
experiment with alternate design patterns, data types, etc.
What music do you like?
Growing up, I started like any child of the 90’s with bubblegum pop and the boy-band craze.
However, my friends and I soon filled our suburban homes with gangster rap, changing our debates
from ’Nsync vs. Backstreet to Biggie vs. Pac. By sophomore year of high school, I was swept up
in the rise of Denver’s electronic scene, keeping my neighbors awake with the relentless thumping of
hardcore techno. These days, I listen to just about anything, but as a DJ I like to incorporate the
popularity of hip-hop with the danceable beats of Dubstep and House.

---