Team 4 - Sound Effects Wand
From SoftwarePractice.org
Introduction
This article has been created to aid project team four (for Object Oriented Design 2007 spring semester) in their completion of the objectives of the aforementioned course. This introduction in particular is a test of the tools of the wiki; Currently, it exists primarily to allow me to learn how to use wiki.
Having checked the course category, I see that our heading does not follow the naming convention of the other groups reading Team 4 rather than T4. This will hopefully not be a problem.
modified the team registration list: The link now goes to this article rather than T4. I would create a changes log but I believe the software keeps track of changes automatically. Will probably delete all this rambling and write a real introduction soon.
Group Members
Andrew Iskander 10591131
Ariel Michael 10041628
Rui Huang 10451817
Objectives
Our group has chosen the Sound Effect Wand as our project.
The design brief is: This application allows you to play sounds and produce different sound effects through physical movement of the device in which it is housed. The program can be put into different modes, such as neutral, recording, playback and active effects. The screen should display information about the current mode and state of the program.
From this we inferred the following requirements:
1. The application must play sounds, this feature is functionally seperate from sound effects.
2. The application must produce multiple sound effects the sound effect selection should be the result of device movement
3. At least 3 modes of operation: record (records incoming sound), neutral(does nothing) and active effects (sound effect mode). additional modes could include playback, button controlled sound effects etc.
4. device user interface must feature a screen which should display current mode and additional information; volume, sound effect number / name battery life, etc.
Additional design features: since the play sounds feature should be functionally separate from the play sound effects feature, (if this was not the case, why was it listed separately in the design brief) it should play a different set of sounds, possibly actual song files. To do this effectively, we need to add common mp3 player functionality to the device e.g. skip, search, stop, pause... Record mode, never defined in the design brief is taken to mean recording incoming sound via a physical microphone on the device like the old Walkman casette players. As an expanded functionality to the motion control, other operations of the device, select mode, etc could be controlled by motion control like sound effects selection.
Note: Many of the additional design features could not be implemented in the prototype due to time constraints.
More about the device will be explained throughout the wiki.
Design Requirements
- Device display should feature a GUI on an appropriately sized screen, display should show mode the device is in and additional information such as battery life percentage of file played (in playback mode) amount of time spent recording so far (in record mode), etc.
- Input controlled by buttons and motion control.
- multiple sound effects, controlled by motion control.
- 4 modes of operation: record, playback, sound effects and ignore input (neutral).
- common sound player functions: skip, search, stop, pause and play included as operations.
Stakeholders
Product Users
The product users are the users of this product. They primarily use the device for the musical and sound playback of the device. The user may also be a musical enthusiast and choose to create and record their own music or sound effects with the motion sensor.
Musicians
The device may assist musicians in order to create music with the sound effect device as it allows them to express their ideas freely. Musicians can also remix songs with the device as the device allows the user to playback music that is being stored on the device and also record the unique sound at the same time.
Retail Stores
The device will be in demand as it is being sold in retail stores, this is important as we need to market the device to be profitable. Also, in order to allow the device to be profitable we need to keep in mind to design the device to be simple and easy to use.
Software Company
The device's software will need to be written properly as many of the functions of the device are based on the instruction of the software itself. The software on the device is also important as it governs the Graphical User Interface (GUI) of the device.
Usage Scenarios and Use Cases
Usage Scenarios
1
A musician picks up the wand to record music and mix existing music with sound effects. The musician uses the buttons feature to select what they want to do with the wand, e.g. play a track. While playing the track, the musician sets the wand to the motion feature to add sound effects to the track.
2
A teenager is using the wand like an Ipod and a Nintendo Wii. They pick up the wand, use the buttons to select song tracks to play and also use the wave motion to record sound effects of their own as if they were a DJ.
3
Tim wants to use the sound effects wand to listen to music. First he presses the power button to switch the wand on, then he selects playback by pressing the "play" button. The wand compiles a list of all the songs stored in its' flash memory and begins playing the first. Tim wants to listen to a different song so he uses the movement controls to jump forward three songs to the one he wants to hear. Then he adjusts the volume via the volume dial and locks the devices input so that he does not change any settings as he moves around and starts to listen. Half way through the song, Tim meets a friend and out of politness decides to turn off the music. He unlocks the wand and stops the song, the device clears the playlist and stands idle. While he is talking, Tim decides that he wants to use the devices sound effects feature to help enounciate his conversation. He removes his head phones to switch the device over to its' internal speaker, switches on the sound effects mode and over the course of several minutes uses the motion input to play six different sound effects of varying appropriateness to the conversation.
Use Cases
Musician and Teenager Use Cases
Use case Diagram
CRC Cards
This is the second iteration of CRC cards for the project. The older set of CRC cards is available Here: UTS 48024: Object-Oriented Design Spring 2007 team 4 old CRC cards.
Changes to design:
- It was decided that volume control would be handled by hardware.
- skip and search combined into one class
- button and movement simulator split into 2 classes
Thus: new list of classes:
- user interface
- button simulator
- movement simulator
- button
- movement
- playback
- record
- skip/search
- stop
- pause
- sound effects selector
- songlist
- play
and 2 simpler classes that are only kept separate and not combined with another class for clarity:
- main
- lock controls
Class Diagram
Initial rough class diagram now located here: UTS 48024: Object-Oriented Design Spring 2007 team 4 old class diagram
New Diagram (not including latest changes) here: UTS 48024: Object-Oriented Design Spring 2007 team 4 new class diagram
Sequence Diagrams
Musician and teenager sequence diagram -
One of our general sequence diagrams -
User Interface Design Sketches
The following are only prototype designs of the GUI of the Wand device, the final design will be presented in the next milestone presentation
Andrew's GUI/design sketch
Rui's GUI/Design sketch:
When the Wand is recording the users movement with the wand feature and the same time generating Sound FX or music.
The device is playing back a song or Sound FX from the device memory.
User is accessing the Wands file menu system, indicating to the user what files are available to play.
The final user interface:
Design Assumptions and Decisions
General layout of the Graphical User Interface
We want to allow the user to have an unique feeling with the Graphical User Interface (GUI), yet at the same time we want to feel as if they are already familiarise with the device from previous experiences. The layout will be different however, other indications or icons such as:
- Play/Pause
- Stop
- Record
- Fast Forward/Next
- Rewind/Last Song
Will be the same with other device on the market.
We also want the user can access functions and features easily rather than searching for menus then sub-menus which can cause confusions. Overall, as we are designing the GUI it is important that we keep in mind that user should have an easy experience using the device.
Milestone 1 Presentation
Could not upload file
Breakdown of class coding responsibilities
As described elsewhere on the wiki, the final list of classes are as follows: new list of classes:
* user interface * button simulator * movement simulator * button * movement * playback * record * skip/search * stop * pause * sound effects selector * songlist * play
and 2 simpler classes that are only kept separate and not combined with another class for clarity:
* main * lock controls
The Breakdown will be as follows: Each Group member will be responsible for coding 4 of the main classes except for one group member who will code 5. Two of the Group members will each take one of the simple classes to code.
Team Members' Contributions
Andrew Iskander
Class Contributions
- Main Class - All code
- MainWindow2 Class - All code
- WandInterface Class - All code
- MainWindow Class - All code
- ButtonsPanel Class - All code
- MidiFile Class - All code except for effects code
Ariel Michael
From the list of classes:
* user interface * button simulator * movement simulator * button * movement * playback * record * skip/search * stop * pause * sound effects selector * songlist * play
I have coded:
- movement simulator (embedded into midifile class in final program)
- movement
- sound effects selector (renamed sound_effects in final program)
- play (renamed Midi in final program as part of an unimplemented plan to offer multiple file type compatibility)
Rui Huang
Personal Summary
Although, we try to provide as much features on the wand as much as possible, we realise that for some of us, especially me personally the coding of the project may be a bit too difficult.
We end up using keys to simulate the accelerometer. There are some features we did not end up putting in to the program. Such as Record and Search. These are some last minute features that we thought off but decided not to incorporate in to the program.
Class Contribution
- Record
- Search
Class Descriptions
Classes coded by Ariel
I coded four of the Classes for the program comprising the movement controlled sound effects selection and generation. The four classes coded were:
- play (later called Midi)
- sound effects selector (later called sound_effects)
- movement
- movement simulator (embedded into midifile)
Midi
Beginning with the lowest level class: Midi. Midi was designed to play a Midi format sound file if passed a file path as a string. The program checked that the file existed and had the correct extension, exiting if either of these conditions were not met. If both conditions were met the class would play the passed file once from beginning to end and then close.
sound_effects
This class functions under the assumption that a set of effect files exist in a folder on the c: drive of the computer where the program is run. this folder represents the drive of the finished device where the sound effects would be stored. On being passed a number corresponding to the appropriate sound effect, 1 - 6, the program loads a corresponding file path from an internally stored array of file paths and passes it to the Midi class.
movement
before we can continue, it becomes necessary to explain the workings of the basic accelerometer:
Accelerometer investigation: The basic accelerometer comes in 2 types, analogue or digital. An analogue accelerometer outputs data as a varying voltage, digital outputs via varying the frequency of a square wave voltage output. The accelerometer tends to output 3 signals, one for each axis which is typically formated by hardware to produce 6 signals 3 for acceleration and 3 for gravity thus 2 values for each axis. I selected the analogue accelerometer as the sensor our device would use as I find such a device easier to visualize. The voltage output is generally formated by hardware to provide a series of output numbers at discrete intervals and I am assuming that the accelerometer in our device is being formated in a similar way outputting 3 acceleration values limited from + to - 100 and 3 gravity values formated from + to - 10. The gravity values are there but not made use of.
The movement class is passed 6 values as long variables representing accelerometer input. The data is sent once every 20th of a second nominally. and compiled into temporary arrays within the class to establish a stream of values for the last half second. Then, the stream of data is analyzed for any trends showing definite acceleration in one direction. if such a trend is found a signal is sent to the sound effects selector class.
movement_simulator
There is no way to accurately simulate an accelerometer without employing a real accelerometer. This class passes a pre generated string of numbers to the movement class in response to a single input (button press) from the user. I could have done something that allowed the user to send strings of number data by say moving a mouse or hitting key but: it would not have been an accurate simulation, it would have been hard to use, and generating a large stream of numbers is a job for a computer anyway. For these reasons I went with my method.
