Transcript rMUSIC – A Collaborative Music DJ for Ad Hoc Networks

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
Fixed Resource
Clients
Mediation
Server
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
Change Weight
(w/ maxChange = 4.47)
5
4.5
3.5
3
2.5
2
1.5
1
0.5
Target User's Rating
95
10
0
90
85
80
75
70
65
60
55
50
45
40
35
30
25
20
15
10
5
0
0
Change Weight
4
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.