A Collaborative Music DJ for Ad Hoc Networks Ursula Wolz Mike Massimi Eric Tarn Department of Computer Science The College of New Jersey

Introduction rMUSIC is a way to collaboratively design a music playlist at a small gathering Aims to reinvent the way groups of people share music amongst themselves Research goal:  To develop collaborative solutions to problems of sharing fixed resources.

Why Formalize Social Events? Introduction of a computer-mediated system…  Allows study of social patterns.  Removes the need for a specified DJ (who may not share musical tastes with the partygoers).  Engages partygoers on a personal level.  Permits another dimension of interactivity with the music.

A Common rMUSIC Scenario A group of people gathering at a social function where music is to be played. Each individual contributes his/her own music to the group’s collective library. There is no specific DJ – everyone is involved in choosing music. Everyone has a different taste in music. Small nightclubs/discotheques, dorm rooms, apartments, karaoke bars, etc.

What rMUSIC Does The songs residing on each mobile device are registered with the server (NOT copied). Songs can then be chosen by anyone else at the gathering by selecting them on their mobile device. Position of songs on the playlist can be altered by using the mobile device.

Why it’s time for the “Modern Sock-Hop” People demand interactivity and are no longer content to passively consume music. Portable music players often contain media that people would like to share with a group. People create their own playlists “on the fly” – playlists change and evolve during the social event.

Assumptions People will always want to share music with others because it’s personal and fun. Gatherings where music will be played occur frequently. People often have different tastes in music and want to share their personal preferences with others. Everyone has their own personal music player with rMUSIC client software and wireless connectivity.

How The Dynamic Playlist Is Formed Problem:  Forming a playlist that appeals to the most number of people.  First-In First-Out models are subject to abuse and does not maximize satisfaction.  Deterministic algorithms cannot capture the subtleties of mixing music for a unique crowd. Solution:  The best “mix” evolves from group decisions.  A.I. technique to balance ratings prevents “dominance” and “lockout.”  Needs user involvement through voting.

rMUSIC Architecture Diagram Mediation Server Clients Fixed Resource

rMUSIC Client Discovers the rMUSIC server in a wireless network and then registers itself. Generates a listing of songs that the user wants to share (kept in a pre-specified directory). Displays interface to interact with the server. Continually updates in order to show changes. Interacts with user to create changes in the playlist. Source of streaming music for the current song.

rMUSIC Server First registers and authenticates clients. Indexes play list and rating of individual clients. Stored procedures for:  Playlist management  Client rating management  Referenda management  Mediates song selection with audio player

Voting User involvement in determining the playlist through voting. Any user can cast a vote for or against songs that other users propose. Each user has different ability to influence the movement of a song through the playlist as determined by their rating. Change in rating is determined non-linearly and is more difficult as ratings reach extremities.

Algorithm and Balancing Ratings To prevent domination/isolation of particular members, a nonlinear model is used (i.e. when a rating changes, it changes by a different amount each time). Calculates ratings based on the difference between the ratings of the users involved.

Graph of Change Weight

Simulation Results

Current Implementation Java 2 Standard Edition desktop client.  Moving towards a J2ME mobile client on Sharp Zaurus. MySQL database used to manage playlist and users. Wired ethernet connection.

Drawbacks Our balancing formula makes it more difficult for users to abuse the system, but is by no means bulletproof. Need to fine-tune the user interface. Impact on system resources untested.

Summary Contributes by formalizing the dynamics of social interaction and music preference at parties. Provides a framework for examining situations of abuse, dominance, submission, and user experience. Current work includes a realization of the theory, as it relates to music and to a virtual interactive museum.