T1 : Head-Controlled Music Player
From SoftwarePractice.org
Introduction to Project
A need has been identified for a device that can allow a person with only the control of their head to interact with a sound system for playing recorded music.
The vision is for this device to consist of a small, wearable accelerometer that measures the direction, tilt and acceleration of the person's head in order to derive input control commands necessary to operate the sound system. The accelerometer communicates over wireless with the sound system to control the selection, playback, volume and the other features of the system. The sound system contains a graphical user interface (GUI) that displays various options for the user such as the current track, a play list and the duration of the track. The system can play tracks in .wav and .mp3 format.
The GUI also contains a separate panel that shows a visual indication of the user's head movements, and associated commands.
Team Members
Sheldon Huang ( 10430231 )
Mohamed Elwan
Nawaz Isaji
Lukshi Mahendran (10175065)
Team Page
Interpretation of System Requirements
The following requirements form the basis of our assumptions in outlining the system elements, key risks and usage scenarios.
- The system allows the user to access the music stored in the player using a specific set of head-movements.
- The music player may be used as a sound system within the user's residence or as a portable music player, mounted on a wheel chair or other such vehicles.
- Requirements:
- A user-friendly GUI that allows for easy manipulation of menu options using limited head movements
- Simulation of the user's head movements
- Display the user's current head position on the screen (as a grid) in real-time so that they can determine what movement is required to select options
- Save preferred user settings and music tracks
- Include a 'hold' mechanism to prevent unwanted selection of options
Key System Elements
List of elements of the system that the system will require:
- User/s
- Wireless Accelerometer
- Java-enabled PC with sound-card, speakers and/or headphone jack
- System:
- GUI
- Java .mp3 and .wav player
- Simulator/Sensor
- Song database
- Instruction Manual
Key Stakeholders
As a team, we have identified a list of stakeholders, who may be interested in such a device.
- Users
- Disabled/Paraplegics - will be able to independently access a musical source.
- Non-disabled users - may be required to assist their disabled friends/family to use some aspects of the player such as putting on the head-phones
- Programmers
- Software developers - will need to explore ways to make the device user-friendly and more efficient in terms of customised features
- Wheelchair manufacturers - may look into adding this feature as part of their product to increase appeal and revenue
- Mp3 hardware manufacturers - will benefit from venturing into a line of products aimed at disabled people
- Mp3 software manufacturers - may need to explore the various ways this system could be better designed to cater for the needs of various disabilities
- Societies for disabled persons (e.g. Spinal Cord Injuries Australia [1]) - may promote the use of this device to their patrons to enable them to experience new technologies
- Engineers Australia - fund for research into further development of such technologies that allow people with disabilities to experience some aspects of normal life
- IEEE (For standards in manufacturing this device) - may need to put forward a set of standards that ensure safety when this product is commercialised.
- ICCC (International Council for Caring Community) - may show interest in promoting new technologies to a sector of the international community that has been ignored by some technology enterprises.
Key Risks
- Risks from malfunctioning system elements:
- Possible overheating of the head device.
- Accelerator's wireless signal strength not sufficient to communicate to the system
- Biological risks - the signal may be harmful for the brain exposed to the signal for extended periods of time
- User may suffer hearing loss or feel frustrated due to an inability to control the volume levels, select tracks etc. if the wireless signal is weak
- Risks from Design elements
- Inconvenience to the user due to the need for many head movements.
- Confusing/complicated GUI design
- The amount of movement required to change settings should consider the capabilities of the user
- Unrealistic expectations of movement (for example, expected to keep still while listening to music so as not to cause unexpected selection of options)
Usage Scenarios
Disabled Users
1. Tom is using the head-controlled music player and realises that there is a delay in communication from the accelerometer to the player. He realises this could cause problems when he needs to adjust volume urgently and sets the volume to a maximum level that he is comfortable with.
2. Tran who is 22 uses his head-controlled music player regularly. He feels listening to the tracks in the same order each time is bores him. He accesses the extra options available such as "shuffle" and "random" to listen to his tracks in a more dynamic order.
3. 10 year old Bobby finds the head-controlled music player very useful because it lets him listen to his latest tunes independently. He likes to move his head to the music and finds it causes the music player to skip to the next song or to adjust the volume without him intending it to do so. He uses the 'hold' option and finds it very convenient as it lets him move freely after selecting his song and putting the player on hold.
4. 65 year old Frank is a very simple person. He loves his music from the late 60s but he finds technology is a little too complicated at times. He seeks a device that is not too complicated to use and is trivial.
5. 14 Year old Lisa is an image sensitive person. She wants a player with nice and colourful skins. (may be omitted)
Non-disabled users (parents/carers/friends)
6. Mark is the father of Bobby. Every time Bobby needs to get out of the house, he asks Mark to sync the latest tracks into the portable version of his music player because he can't connect the USB to the system himself. Mark feels this arrangement is inconvenient for him and that it would be better if the system provided a way for Bobby to do this task himself.
7. Leisa is presented with the head-controlled music player by her parents and finds it very entertaining. Her family however wants her to use the headphones so that they won't be disturbed when she uses it. Leisa requires the help from her family to put the headphones on.
Use Cases
- Enter songs into player
- Use head movements to select options
- Use the 'Random' option to play songs
- Use the 'Hold' option to prevent unwanted selection on GUI
Use Case Diagrams
- System overview Case Diagram
- Updated System Overview Case Diagram
- Detailed diagram of use case
- Updated Detailed Use Case Diagram
Proposed User Interfaces
- Proposal 1: Cyclic-menu selector:
- The current menu that the user is accessing is highlighted.
- The other menus are accessed in a cockwise direction depending on the user's head movement.
- Definition of allowed head movements:
- Right - Next menu
- Left - Previous menu
- Forward - Select menu
- Back - Get back to the main menu
- Once a menu is selected, the above head movements would be used appropriately for that particular menu. For example, within the track list:
- Right - Next track
- Left - Previous track
- Forward - Select track
- Back - Get out of the track menu
Mock-up of GUI proposal 1:
- Proposal 2: iPod design:
- Basic screens can be established using JFrame
- Main benefit is the hierarchy of menus is only on two levels. Can easily access them and return to the main menu without too much pressure on the head.
Mock-up of GUI proposal 2:
Final Graphical User Interface
- Opening screen:
- This version of the GUI incorporates the two proposed GUI during the design process.
- This combination allows for ease of use for both the disabled and non-disabled users as all the options are presented on the surface menu
- All components including track list, volume and grid_panel are present on the main screen. This eliminates the need for excessive head-movements that may be necessary to access hierarchical menus
- Instructions are also displayed on the main screen so as to provide maximum support for the disabled person using head control to access the system.
Screen shot of final GUI
Class Diagrams
CRC Cards
Class Name: Simulator
| Responsibilities | Collaboration |
|---|---|
|
MainFrame - Display the Simulator along with menus and labels that inform the user how the grid panel should be used Player- execute appropriate commands based on the mouse inputs such as play,, stop, next and previous options |
Class Name: MainFrame
| Responsibilities | Collaboration |
|---|---|
|
Simulator- The grid panel drawn by the Simulator class is always present on the GUI to display user head movements. It calls the MainFrame when a valid mouse event is recognised in order to perform the appropriate action Player - Calls the file loading/reading/saving methods as well as play and stop functions to manipulate the tracks according to user inputs Playlist - The play list is displayed on the GUI enabling the user to see the tracks that are currently added to the track list |
Class Name: Player
| Responsibilities | Collaboration |
|---|---|
|
MainFrame Class- Controls the input and output of sound media as selected by the user. This includes the basic controls such as play, pause, as well as tracks and volume selections. Simulator Class - Displays information about user selections. |
Class Name: Playlist
| Responsibilities | Collaboration |
|---|---|
|
MainFrame - Displays the playlist for the all users to access. Songs Class - Contains specific information for each sound file / track such as name, and type. |
Class Name: Songs
| Responsibilities | Collaboration |
|---|---|
|
Provide the categories to store each track such as song name, file name and file type (mp3 or wav)
|
Playlist - saves song information in an array of songList |
Class diagram with all key functional elements
Sequence Diagrams
Sequence Diagrams of important interactions
Class Name: Simulator
Class Name: MainFrame
Class Name: Player
Class Name: Grid_Panel
Quick and Dirty Collaboration Diagrams
Simulator and MainFrame class interactions
Player and Simulator class interactions
Class Specifications
Class: MainFrame
Purpose: The purpose of this class is to present the Simulator, Play list and Volume selection on a GUI for user interaction. The users may control the selection and volume and tracks of the music being played either through the simulator (disabled users) or through the use of buttons (non-disabled users).
General user interaction: The input for this class is in the form of user-initiated mouse events that simulate the user’s head-movements. The output is the movement of a square on the grid panel that represents the position of the head as well as the required changes being made to the different components (e.g. increase in volume).
Associating mouse event and actions to head movements:
Attributes:
VOL_MIN = 0; represents the minimum volume level on the slider
VOL_MAX = 100; represents the maximum volume level on the slider
VOL_INIT = 40; represents the volume level on the slider at start up
songList: JList – Holds the list of tracks added to the player
addButton: JButton = The button used by non-disabled users to add a set of tracks to the player
removeButton: JButton = The button used by non-disabled users to delete a set of tracks to the player
plList: Playlist – reads and saves the tracks added to the player
volume:JSlider = the slider which takes the inputs from the user to control volume levels
previousButton, playButton, stopButton, nextButton: JButton – Buttons presented on the GUI for access by non-disabled users to browse, play and stop songs in play list
pl: Player – The object through which the music player functions are accessed
simulator: Simulator – presents the Grid Panel showing the current head movements to the user
currentMenu, menuText, volText, tracksText: JLabel – Labels for naming each component of the GUI for user information
Operations:
method - setMenu(menu: String)
Input: menu: String
Output:
Precondition: A valid menu object of type JLable exists
Post condition: The current menu is displayed on the GUI
method - goPrevious()
Input: none
Output:
Precondition: the ‘Prev’ button is clicked and there is a track in the position one less than the current track index in the song list (i.e. i-- is valid)
Post condition: The previous track is highlighted on the play list
method - goNext()
Input: none
Output:
Precondition: the ‘Next’ button is clicked and there is a track in the position one greater than the current track index (i.e. i++ is valid)
Post condition: The next track is highlighted on the play list
method - playSong()
Input: none
Output:
Precondition: the ‘Play’ button is clicked
Post condition: The track that is currently selected is loaded and played at the selected volume
method - refreshPlayList()
Input: none
Output:
Precondition: there has been a change to the current play list in terms of tracks being added or removed
Post condition: The track that is currently selected is loaded and played at the current volume
method - actionPerformed(e: ActionEvent)
Input: e: ActionEvent
Output:
Precondition: A mouse event of type MOUSE_PRESSED has occurred
Post condition: if the addButton has been pressed, use the FileChooser class and the Playlist class to get the music file and add it to playlist. If the removeButton has been pressed, clear the track from the list by calling the removeSong() method in the Playlist class. If the Play, Next or Previous buttons have been pressed, call their respective methods in this class. If the Stop button is pressed call the stop() method in the Player class.
method - setVolumne(vol: Integer)
Input: vol: Integer
Output:
Precondition: volume is between the min and max values specified
Post condition: set the volume to the required value
method - getVolumne()
Input: none
Output:
Precondition: a valid value of volume exists
Post condition: return the current value of volume
method - stateChanged(e: ChangeEvent)
Input: e: ChangeEvent
Output:
Precondition: the volume object on the GUI has been changed
Post condition: convert the value returned from the Jslider on the GUI to an appropriate value and pass the volume level to the changeVolumeLevel() method in the Player class.
method - Main()
Input: none
Ouput:
Precondition: All functions are defined as necessary
Post condition: Create an object of the MainFrame class and implement the required methods by integrating the functionality of the other classes.
Class: Simulator
Purpose: This class allows the user to use the mouse buttons to select different options and control the different functions that are associated with the head controlled music player such as play song, stop song, turn volume up/down and change track menu.
General user interaction: Right-button click: Play/Stop track
Left-button click: Change track song
Middle Button Click: Increase/decrease volume
The input for this class is in the form of user-initiated mouse events. The output is visible changes to the graphic content of the screen, in this case, the indication of the position of the head on the grid panel.
Attributes:
private boolean keyPressed: checks weather the key has been pressed
public int Movement=0; is the initialization to check which mouse button has been pressed
private MainFrame mn: is the attribute for the mainframe class and is used as an argument for another class.
Operations:
method: setMouseButton
Input: me: MouseEvent
Output: Precondition: A mouse event of type keypressed has occurred
Post condition: If the right button has been pressed and if the movement is within 1, the playSong operation is called otherwise if mouse movement equals to 2 then the stop command is initiated.
method:setMouseButton
Input : me : Mouse event
Precondition: A mouse event of type keypressed has occurred
Post condition: If the left button has been pressed and if the movement is within 1, the gonext method is called otherwise if mouse movement equals to 2 the go previous method.
Goprevious corresponds to going to the track previously selected and go next corresponds to going to the next track on the list.
method:setMouseButton
Input : me : Mouse event
Precondition: A mouse event of type keypressed has occurred
Post condition: If the middle button of the mouse is pressed and you are within the range movement of 2, then the volume is incremented using 1 unit otherwise if you are within the range 1 then the volume is decremented by one and the slider appears to reduce the volume.
After the end of each operation the head position indicator is initialized back to 0,or the centre of the origin of the grid panel.
method:Point adjustNewPoint
Input : Point
Precondition: a mouse even of type keypressed has occurred and is within the grid panel range
Post Condition: if the range that the mouse was clicked is within Y<0 and X<0 then this is classified as a movement 2 else if its within the range of y>0 and X>0 then this is calssified as a movement 1 and the appropriate function is performed
Class: Player
Purpose: The purpose of this class is to play and stop the songs in the playlist, control the volume and volume slider and keep the volume loop going
General user interaction: The user interaction for this class comes from the slider of the volume, which then corresponds to the gain. The play and stop buttons of course, simply correspond to stopping and playing the songs from the JavaSound library.
Attributes: filename = the current file loaded in the player or playlist.
isLoaded = parses the file currently loaded in the playlist.
isPlaying = parses the file currently playing in the player, as opposed to that loaded in the playlist.
loadFile = loads the file into the playlist, whilst the play button loads it into the player.
this.currentVolume = parses the current volume running through the player – has a range between 0 and 100.
changeVolumeLevel = changes the volume as reflected by the user input to the slider.
gainControl.setValue = takes the volume decimal and calculates the change in gain based on a logarithmic ratio.
Class: Playlist
Purpose The purpose of this class is to add and remove songs from a source folder into the player database. The class creates an array in which the file names will be added into or deleted from. The file names are taken from the source folder and put into the array, then the song name is taken to be displayed on the Graphical User Interface.
General User Interaction The input for this class is based on two buttons on the Graphical User Interface, 'Add' and 'Delete' The output of this class will be displayed on the GUI as a new song is added a new song name will appear and if deleted the song name will disappear.
Attribute
ArrayList plList = new ArrayList() - Creates a new array as the playlist for the songs to be added into or removed from.
Operations
method - getSongCount()
Purpose: Count the number of objects in the array. Input: Output: Precondition: An array must be generated Postcondition: none
method - addSongToPlayList
Purpose: If the file exists, the file name is extracted and entered into the playlist array. Input: string Output: Precondition": Designated song must exist in the source folder. Postcondition: Song will be added into the playlist array.
method - getSongName
Purpose: Load the song name onto the GUI for display. Input: Output: Precondition: Designated song must exist in the source folder. Postcondition: Song name will be displayed on GUI.
method - getFileName
Purpose: Loads the file name for adding into the array. Input: string Output: Precondition: Song must exist in source folder. Postcondition: File name for the song will be obtained.
method - removeSong
Purpose: Deletes a selected song from the array. Input: string Output: Precondition: Song must exist in array and selectable from playlist in GUI display. Postcondition: The song will be removed from the playlist array and will not appear on GUI.
method - readFile
Purpose: Read, or play a file that is in the playlist if that file still exist on the source folder. Input: string Output: Precondition: Song must be loaded into the array. Postcondition: The song is played.
method - saveFile Purpose: Saves the array of song files for later use. Input: string Output: Precondition: Array must be created. Postcondition: All information in the array is saved and ready for use afterwards.
Test Cases
System Tests
| Requirements | Implementation |
|---|---|
|
Completed -
Not completed -
|
- See Unit Test cases for detailed testing of each class used
Unit Test Cases
Class: MainFrame
Please refer to the class specifications for the full description of operations, attributes and events.
Test Cases for MainFrame Class: All these testcases were passed
Class: Simulator
Class: Player
Nawaz
Class: Playlist
Conclusion/Reflection
By engaging and committing to this project we have learned and improved our skills in many ways. We have improved our team skills and further developed our communication skills as it was crucial for our team to operate in a co-coordinated manner. We also had to integrate the code effectively to match the design specifications. Multi-tasking and time management became essential towards the later stages of the project. We had to rely on each other and also on ourselves to deliver tasks at on time.
We found the flexible nature of the design specifications very helpful as it allowed some creativity on our part in deciding the functionality of the system. Although time constraints prevented us from implementing all the additional functions we set out to do such as allowing the user to select songs at random and providing the user with the 'Hold' option, we are fairly satisfied about the functionality of the final product.
We believe we have met the essential criteria of designing the prototype of a user-friendly music player that allows the user to interact using a combination of mouse movements. We have designed the simulator class of the system in a cohesive rather than a coupled manner so that it may be used in future applications with different head movements.
Overall, we found this project challenging as well as enjoyable.
Research Links
Java sound API
Modelling Class Diagrams:
http://www.agilemodeling.com/artifacts/classDiagram.htm
This is a site I found on how to extend JavaSound API to play .mp3 files. Click on documents, there are also examples of java music players available:
Getting started with Java Sound:
Components necessary to play .wav and .mp3:
Sample Player:
sound deviation guide:
Image:Sound dev guide 1.4.2.pdf
Java Media Framework API (JMF):
Other useful links:
Wikipedia: How to edit a page in Wiki
References:
- Schildt Herbert, 2007, Java: the complete reference, 7th edition, McGraw Hill, New York
- Barnes David J, Kölling Michael, 2006, Objects first with Java: a practical introduction using BlueJ, 3rd Edition, Pearson/Prentice Hall, Harlow, England; New York
Instructor comments
Wonderful start. Good interpretation of system requirements and risks. Good identification of stakeholders. The usage scenarios are reasonable, although you should probably indicate what type of user -- disabled, carer, etc. Lian 21st March
Post presentation session milestone: Very good set of stakeholders. Very good set of risks. Good empathy with disabled users. Usage scenarios are great, could include more specifics of disability. Choice of classes okay. On CRC cards, can split responsibilities further, so the mapping from responsibility to collaborating classes is clearer. Some CRC cards are missing for some of the classes. Class diagram ok. Great work with the GUI layout and usability for disabled users. Sketches of sequence and collaboration diagrams shows thoughtful exploration of object interactions. Excellent work so far. Lian 4th April
