From SoftwarePractice.org

Contents 1 Group 2 Requirements 2.1 Basic Requirements 3 Assumptions 3.1 Accelerometer 3.1.1 Reasoning 3.1.2 Consequences 3.2 Intended Devices 3.2.1 Reasoning 3.2.2 Consequences 4 Uses 4.1 Scenarios 4.2 Essential 4.3 Detailed 5 Detailed Specification 6 Class Diagram 6.1 Initial 6.2 Final 6.2.1 Complete Application 6.2.2 Events Package 6.2.3 Sounds Package 6.2.4 Interfaces Package 7 Sequence Diagram 8 Testing 9 GUI Drafts 9.1 Draft 1 - Main Screen 9.2 Draft 2 - Main Screen 9.3 Final 9.3.1 Recording 9.3.2 Playback 9.3.3 Final Comments 9.3.3.1 Meeting Requirements 9.3.3.2 GUI 9.3.3.3 Java Implementation 9.3.3.4 File Format 9.3.3.5 Application

Group

10440319 - Kaushal de Silva

Requirements

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. The device contains a small accelerometer that measures the direction, tilt and acceleration of the device. The graphical user interface should provide a visual indication of the movements of the device, and associated commands.

Basic Requirements

• The application must allow for the manipulation of sound sequences by the physical movement of the host device.
• The application must allow recorded sound sequences to be saved on the host device.
• The application must allow opening and playback of previously saved sound sequences.
• The application must display the current recording/playback status.
• The application must display the relative physical movement of the device from its standing position (in real-time).
• The application must function on the Intended Devices

Assumptions

Accelerometer

It is assumed that the accelerometer avilable in the device functions in the following way;

• The accelerometer is a 2 dimensional (not 3 dimensional) accelerometer.
• The accelerometer outputs 2 values; the x and y positions relative to its origin.
• The x and y values are floating point which range from 0 to 1; 0 being its origin and 1 being its maximum displacement.

An example of a suitable acceleromer

• http://www.dimensionengineering.com/DE-ACCM2G.htm

Reasoning

• This application will be tested on a computer before being deployed; targetting a 2 dimensional accelerometer simplifies this process, as monitor coordinates can be translated to the application in place of physical movement in a sensical manner. This also simplifies the display output process.
• Having only x and y values for input (as opposed to tilt and acceleration) simplifyes the process of displaying the physical movements on screen.
• Floating point values (as opposed to integer values) for x and y will allow for precise calculations of tilt and acceleration, and reduces chances of rounding errors.

Consequences

• Due to the 2 dimensional accelerometer, only 2 axis of movement will be recorded, meaning only 2 attributes of the sound sample can be manipulated at any one time.
• Due to the x and y value inputs, the application will have to calculate and maintain tilt and acceleration data in the device's memory.
• Floating point operations are more processor intensive than integer operations.

Intended Devices

It is assumed that the intended device for this application is a mobile device with a full Java 2 Standard Edition implementation. This application cannot be developed for Java 2 Micro Edition due to feature limitations.

Reasoning

• The sound creation functionality requires the use of the Java Sound API, which is unavailable in the J2ME implementation.
• The Media API available in the J2ME lacks advanced features required for this application.
• For saving and playback of sound sequences, the application requires direct access to the File System, which due to security sandboxes and non unique hardware profiles, is unimplmented in the J2ME standard.

Consequences

• Due to the need of the full J2SE implmentation, this narrows down intended devices to Laptops, Tablet PCs, UMPCs, PDAs and similar hardware. This means most cell phones and even smartphones cannot be supported.

Uses

Scenarios

Bob picks up his Tablet PC and starts recording movements with the application. He moves his Tablet in circular motion. He stops recording and replays the sound sequence. He exports the sound sequence as a MIDI file and sends it to his cell phone, and uses it as his ringtone.

Jane opens a sequence file she created yesterday. She records another sound sequence. She combines both recordings and exports its as a MIDI file.

Essential

Detailed

Detailed Specification

• The application must create a MIDI sequence via the movement of the host device.
  • The application must request the current relative position of the device and change the MIDI sequence accordingly.
    • The postion must be repeatedely requested at a suitable interval.
    • The x displacement must vary the key/chord of the current note.
    • The y displacement must vary the volume of the current note.
• The application must draw the movement path whilst creating the MIDI sequence.
• The application must allow for saving of recorded sequences.
• The application must allow for opening of recorded sequences.
  • The application must redraw the movement path as the opened sequence is replayed.
• The application must allow for exporting of the recorded sequences as .MIDI files.
  • The application must allow for opening and combining of multiple sequence files to create a multi track sequence.

Class Diagram

Initial

Final

Complete Application

Media:midimachine.pdf

Events Package

Media:midimachine.events.pdf

Sounds Package

Media:midimachine.sounds.pdf

Interfaces Package

Media:midimachine.interfaces.pdf

Sequence Diagram

Testing

In order to test the application without an accelerometer, a seperate application will be created to simulate the accelerometer.

• This application will simulate the x and y movement of the device by the x and y position of the mouse cursor within a bounding area on the screen.
• This application will repeatedly append x and y values to a text file, which the main application can access at any interval to extract the last recorded position.

GUI Drafts

Draft 1 - Main Screen

Draft 2 - Main Screen

Final

Recording

Playback

Final Comments

Meeting Requirements

Most requirements were met, however the 'combining of sequences to create multi track MIDI files' could not be met for a number of reasons;

• At the stage of initial feasibility study, not enough was known about the Java Sound API and the amount of work required to create multi channel MIDI files, as well as the opening and displaying of multiple sequence files.
• Following on from the previous point, there was not enough time to implement the Combination feature.

GUI

The final GUI ended up looking like Draft 1, instead to Draft 2, this was due to

• Inability to implement Combination feature.
• Changing target device to be similar to a PDA as opposed to a Tablet PC, which limited screen size.

The fast forward / rewind options were removed as they further complicated the interface without any useful gain (most recordings are of 10 - 30 seconds, there is no need to seek).

Java Implementation

The final implementation differed in a number of ways from the initial Class Diagram;

• The InputSource class was initially only to be used by the Recorder, however it was promoted to a the global level where it was usable by all classes. This was due to problems with efficiency; The former required a thread running in the InputSource, and another thread running in the Recorder, by using the latter, the need for the second thread was eleviated.
• Following from the previous point, it was decided the application will follow an observer model, where the InputSource will always broadcast messages, and any other part of the application that required this information can listen to these events. This led to the need for a SampleReciever interface.
• Following from the previous point, when a sequence is to be played back, the display was required to respond to the current playposition in the Recorder instead of the InputSource, therfore a SampleSource interface was created to describe an object that broadcats events. By implementing this interface from both InputSource and Recorder, it was possible for the Display to listen to both (one at a time) without type conflicts.
• As there can only be one instance of the application, it was decided that Application will be a singleton, acting as a single communication medium between the Recorder/Display and InputSource.

File Format

An ASCII based file format was created for storing sequence data. It is as follows...

X,Y
X,Y
X,Y
X,Y
X,Y
X,Y
X,Y
X,Y
X,Y
X,Y
EOF

... where a single line is a Sample, and X and Y represent the X and Y displacements of the device.

As we save the raw input from the accelerometer, this allows us to not only play back the sequence exactly as recorded, it also means that we can use the coordinates to redraw the exact path in the Display.

Application

Media:JavaAppliation1.zip