final report draft.docx - grppro

weaverchurchΛογισμικό & κατασκευή λογ/κού

15 Αυγ 2012 (πριν από 4 χρόνια και 11 μήνες)

463 εμφανίσεις


Keyboard Hero

G52GRP
Final Group Report

Group: gp08
-
nhn

1
st

May 2009



Group Members

Sarper Aydogan (sxa37u)

Daniel
Nicholas
Kiss (dnk07u)

Ricardo Oliveira (rdo07u)

Jia Shi (jxs18u)

Oana Stan (oxs18u)

Zuonan Yang (zxy18u)

Supervisor: Dr
.

Henrik Nilsson



gp08
-
nhn

Dr. Henrik Nilsson

Page
2

of
62


TABLE OF CONTENTS

Introduction

................................
................................
................................
................................
................................
................

7

Original Problem

................................
................................
................................
................................
................................
.....

7

Updated Desc
ription of the Problem

................................
................................
................................
................................
......

8

Musical Input

................................
................................
................................
................................
................................
......

8

Visual Feedback

................................
................................
................................
................................
................................
..

8

Multiplayer
Functionality

................................
................................
................................
................................
...................

8

Research

................................
................................
................................
................................
................................
....................

10

Existing Systems

................................
................................
................................
................................
................................
....

10

Console Video Games

................................
................................
................................
................................
.......................

10

Online Role Playing Games

................................
................................
................................
................................
...............

11

Flash/Applet Systems

................................
................................
................................
................................
.......................

12

Research Overview

................................
................................
................................
................................
...........................

12

Musical Interfaces

................................
................................
................................
................................
................................
.

13

Musical Instrument Digital Interface (MIDI)

................................
................................
................................
.....................

13

MIDI Messages

................................
................................
................................
................................
................................
.

14

MIDI File Format

................................
................................
................................
................................
...............................

16

MIDI Sequenc
ers and MIDI Synthesizers

................................
................................
................................
..........................

16

Requirement Specification

................................
................................
................................
................................
........................

18

Introduction

................................
................................
................................
................................
................................
..........

18

System Overview

................................
................................
................................
................................
..............................

18

Users

................................
................................
................................
................................
................................
.................

18

Assumptions

................................
................................
................................
................................
................................
.....

18

System Requirements

................................
................................
................................
................................
...........................

18

Functional Requirements

................................
................................
................................
................................
.................

18

Non
-
Functional Requirements

................................
................................
................................
................................
.........

19

Initial Design

................................
................................
................................
................................
................................
..............

22

System Design

................................
................................
................................
................................
................................
.......

22

Diagramming Conventions

................................
................................
................................
................................
...............

22

Context Diagram

................................
................................
................................
................................
...............................

22

Level 0 Diagram

................................
................................
................................
................................
................................

23

gp08
-
nhn

Dr. Henrik Nilsson

Page
3

of
62


Level 1 Diag
ram

................................
................................
................................
................................
................................

23

Comparison Algorithm

................................
................................
................................
................................
..........................

26

Overview

................................
................................
................................
................................
................................
...........

26

Graphical User
Interface

................................
................................
................................
................................
.......................

27

Introduction

................................
................................
................................
................................
................................
......

27

Overview

................................
................................
................................
................................
................................
...........

27

Diagram

................................
................................
................................
................................
................................
............

28

Future Revisions

................................
................................
................................
................................
...............................

28

Implementation

................................
................................
................................
................................
................................
.........

30

Implementation Decisions

................................
................................
................................
................................
....................

30

Prog
ramming language:

................................
................................
................................
................................
...................

30

Operating systems:

................................
................................
................................
................................
...........................

30

Hardware:

................................
................................
................................
................................
................................
.........

30

Software:

................................
................................
................................
................................
................................
..........

31

Classes

................................
................................
................................
................................
................................
..............

31

Graphical User Inter
face

................................
................................
................................
................................
.......................

34

Introduction

................................
................................
................................
................................
................................
......

34

Implementation

................................
................................
................................
................................
................................

34

The Menu Bar

................................
................................
................................
................................
................................
...

34

The Information
Panel

................................
................................
................................
................................
......................

35

The Game Panel

................................
................................
................................
................................
................................

35

The Keyboard

................................
................................
................................
................................
................................
....

36

The Status Bar

................................
................................
................................
................................
................................
...

36

Project Anaylisis

................................
................................
................................
................................
................................
........

38

Introducti
on

................................
................................
................................
................................
................................
..........

38

Requirement Analysis

................................
................................
................................
................................
...........................

38

Functional Requirements

................................
................................
................................
................................
.................

38

Non Functional Requirements

................................
................................
................................
................................
..........

41

Project Organisation

................................
................................
................................
................................
.............................

41

Software

Process Model

................................
................................
................................
................................
...................

41

Roles and Responsibilities

................................
................................
................................
................................
................

41

gp08
-
nhn

Dr. Henrik Nilsson

Page
4

of
62


Problems Encountered

................................
................................
................................
................................
.........................

42

Time Plan

................................
................................
................................
................................
................................
..............

42

Project Analysis

................................
................................
................................
................................
................................
.........

43

Project Appraisal

................................
................................
................................
................................
................................
...

43

Future Developments

................................
................................
................................
................................
...........................

43

Final Comments

................................
................................
................................
................................
................................
.........

45

Acknowledgements
................................
................................
................................
................................
...............................

45

Bibliography

................................
................................
................................
................................
................................
..............

46

Testing

................................
................................
................................
................................
................................
.......................

48

Unit Testing

................................
................................
................................
................................
................................
...........

48

Peer Review

................................
................................
................................
................................
................................
..........

48

1
-

Keyboard Hero: Formal Meeting Minutes
................................
................................
................................
............................

50

Meeting Details

................................
................................
................................
................................
................................
.....

50

Next Meeting Details

................................
................................
................................
................................
............................

50

1.A


Review Problem Specification

................................
................................
................................
................................
.....

50

1.B


Interim Report
................................
................................
................................
................................
..............................

50

1.C


Discuss Research and its relevance

................................
................................
................................
..............................

50

1.D


Time Plan

................................
................................
................................
................................
................................
.....

50

Action Points

................................
................................
................................
................................
................................
.........

51

2
-

Keyboard Hero: Formal Meeting Minutes
................................
................................
................................
............................

52

Meeting Details

................................
................................
................................
................................
................................
.....

52

Next Meeting

Details

................................
................................
................................
................................
............................

52

2.A


Welcome and Introduction

................................
................................
................................
................................
..........

52

2.B
-

SVN

................................
................................
................................
................................
................................
...............

52

2.C


Example Games

................................
................................
................................
................................
............................

52

2.D
-

Classes

................................
................................
................................
................................
................................
..........

52

2.E


Graphical User Interface (GUI)

................................
................................
................................
................................
.....

52

2.F Role Assignment

................................
................................
................................
................................
..............................

53

2.G Documentation

................................
................................
................................
................................
...............................

53

Action Points

................................
................................
................................
................................
................................
.........

53

3
-

Keyboard Hero: Formal Meeting Minutes
................................
................................
................................
............................

54

Meeting Details

................................
................................
................................
................................
................................
.....

54

Next Meeting Details

................................
................................
................................
................................
............................

54

3.A


Sub Group Allocations

................................
................................
................................
................................
.................

54

3.B


Gannt Charts

................................
................................
................................
................................
................................

54

3.C
-

MIDI

................................
................................
................................
................................
................................
..............

54

gp08
-
nhn

Dr. Henrik Nilsson

Page
5

of
62


3.D
-

GUI

................................
................................
................................
................................
................................
................

54

Action Points

................................
................................
................................
................................
................................
.........

54

4
-

Keyboard Hero: Formal Meeting Minutes
................................
................................
................................
............................

55

Meeting Details

................................
................................
................................
................................
................................
.....

55

Next Meeting Details

................................
................................
................................
................................
............................

55

4.
A


Interim Report

................................
................................
................................
................................
.............................

55

4.B
-

Achievements

................................
................................
................................
................................
...............................

55

4.C
-

Blog

................................
................................
................................
................................
................................
...............

55

Action Points

................................
................................
................................
................................
................................
.........

55

5
-

Keyboard Hero: Formal Meeting Minutes
................................
................................
................................
............................

56

Meeting Details

................................
................................
................................
................................
................................
.....

56

Next Meeting Details

................................
................................
................................
................................
............................

56

5.A
-

GUI

................................
................................
................................
................................
................................
................

56

5.B
-

MIDI

................................
................................
................................
................................
................................
..............

56

5.C


Interim Report

................................
................................
................................
................................
..............................

56

Action P
oints

................................
................................
................................
................................
................................
.........

56

6
-

Keyboard Hero: Formal Meeting Minutes
................................
................................
................................
............................

57

Meeting Details

................................
................................
................................
................................
................................
.....

57

Next Meeting Details

................................
................................
................................
................................
............................

57

6.A


Interim Report

................................
................................
................................
................................
.............................

57

6.B
-

MI
DI

................................
................................
................................
................................
................................
..............

57

6.C
-

GUI

................................
................................
................................
................................
................................
................

57

Action Points

................................
................................
................................
................................
................................
.........

57

7
-

Keyboard Hero: Formal Meeting Minutes
................................
................................
................................
............................

58

Meeting Details

................................
................................
................................
................................
................................
.....

58

Next Meeting

Details

................................
................................
................................
................................
............................

58

7.A


Interim Report

................................
................................
................................
................................
.............................

58

Action Points

................................
................................
................................
................................
................................
.........

58

8
-

Keyboard Hero: Formal Meeting Minutes
................................
................................
................................
............................

59

Meeting Details

................................
................................
................................
................................
................................
.....

59

Next Meeting

Details

................................
................................
................................
................................
............................

59

8.A


Interim Report Feedback

................................
................................
................................
................................
.............

59

8.B
-

Timeplan

................................
................................
................................
................................
................................
.......

59

Action Points

................................
................................
................................
................................
................................
.........

59

9
-

Keyboard Hero: Formal Meeting Minutes
................................
................................
................................
............................

60

Meeting Details

................................
................................
................................
................................
................................
.....

60

gp08
-
nhn

Dr. Henrik Nilsson

Page
6

of
62


Next Meeting Details

................................
................................
................................
................................
............................

60

9.A
-

MIDI

................................
................................
................................
................................
................................
..............

60

9.B
-

GUI

................................
................................
................................
................................
................................
................

60

9.C
-

Connection

................................
................................
................................
................................
................................
....

60

9.D


Combin
ing groups

................................
................................
................................
................................
........................

60

9.E


Scoring System

................................
................................
................................
................................
.............................

60

Action Points

................................
................................
................................
................................
................................
.........

60

10
-

Keyboard Hero: Formal Meeting Minutes

................................
................................
................................
.........................

61

Meeting Details

................................
................................
................................
................................
................................
.....

61

Next Meeting

Details

................................
................................
................................
................................
............................

61

10.A
-

MIDI

................................
................................
................................
................................
................................
............

61

10.B
-

GUI

................................
................................
................................
................................
................................
..............

61

10.C
-

Communication

................................
................................
................................
................................
..........................

61

10.D


Presentation

................................
................................
................................
................................
..............................

61

Action Points

................................
................................
................................
................................
................................
.........

61

11
-

Keyboard Hero: Formal Meeting Minutes

................................
................................
................................
.........................

62

Meeting Details

................................
................................
................................
................................
................................
.....

62

Next Meeting

Details

................................
................................
................................
................................
............................

62

11.A
-

Presentation

................................
................................
................................
................................
...............................

62

11.C
-

Connection

................................
................................
................................
................................
................................
..

62

11.D
-

Integration

................................
................................
................................
................................
................................
..

62

Action Points

................................
................................
................................
................................
................................
.........

62




gp08
-
nhn

Dr. Henrik Nilsson

Page
7

of
62


INTRODUCTION

Group gp08
-
nhn was assigned the task of creating a
system based on a set of requirements provided by Dr. Henrik Nilsson.
This report details the key decisions and final progress made by gp08
-
nhn.

The report is divided into several sections:

1.

Introduction

details the original problem and an updated problem d
escription

2.

Research

contains a brief overview and analysis of important systems and sources

3.

Requirement
s
pecification
lists all the agreed technical details which will be implemented in the system

4.

System
d
esign

gives a brief description of the final system

design, including the user interface

5.

Implementation

records any major decisions made regarding the system including the method of testing used

6.

Management p
lan
details the group methodology and the time plan for the project

7.

Project
analysis

reviews the problem specification and discusses if the project has met the requirements

8.

Summary

comments of the success of the project, from a technical and group perspective.

Finally, the appendix contains:

9.

Program
t
esting

detailing the testing that was performed

10.

Minutes

cataloging the meetings held by the group

Original Problem

The original problem is described below:

“Guitar Hero is a combined musical and computer game that has become very popular recently. This
project
is inspired by that game, but aimed at keyboard players instead, and with a more educational
scope. It is envisioned that the game will be played by attaching a MIDI keyboard to the computer.

One can imagine many kinds of games. The simplest is perhaps sh
owing the score for a musical phrase
to the player, picked by the computer at random from a library (or maybe even randomly generated),
and asking him or her to play it as accurately as possible guided by a metronome click. Points are
scored depending on h
ow accurately the phrase is played, and the difficulty of the phrase (e.g. tempo,
how involved it is, key, ...). One can imagine variations with one note at a time or chords, and one or
two hands simultaneously. Other variations include asking the player t
o play with a certain rhythmic
feel, like swing, as opposed to as accurately as possible.

To make the game more fun, and more like Guitar Hero, the metronome click could be replaced by a
backing track (either MIDI or audio) for well
-
known tunes.

For ulti
mate fun, consider on
-
line play. It's likely not feasible to broadcast the performance of a player
in real
-
time unless they are on the same local net, but one could easily capture a performance as a
MIDI sequence, and then sending that to the other players

so they can hear how well or badly their
opponents played a particular phrase. One could consider allowing the players to set each other
musical challenges by picking phrases from well
-
known songs as an alternative to the computer picking
phrases at rando
m.

In short, plenty of scope to develop this project in different directions! As a base
-
line, the project should
implement at least a simple variation of the game, and playing over the Internet in some form.“

Dr. Henrik Nilsson


gp08
-
nhn

Dr. Henrik Nilsson

Page
8

of
62


Updated Description of
the Problem

The updated problem
description
is very similar to the original problem with a few extra clarifications. The main focus of
the
system

will be entertainment with scope for adding educational aspects. The description below
divides

the problem
int
o three definable sections.

Musical Input

The system being developed will be capable of handling musical input from both an attached device and a file. The data
gathered from these two sources will be used in a comparison algorithm
, which

will

check the
pe
rformance
and accuracy
of
the input
,

aga
inst the data contained within the

file
. This information will then be used to
generate a scor
e

using a scoring
mechanism
.

Once this has been achieved the data from both the file and device will be processed to
provide aural

feedback via an
output device. The system should also allow for the data received from the device to be recorded for later use.

Vi sual Feedback

A graphical user interface (GUI) will provide visual feedback for the data provided through the ‘m
u
sical


section above. It
will display the data in a way such that the user will be able to relate what is being shown
(graphically)
to what is being
requested of them

physically (playing a note on a keyboard)
.
The GUI will also allow the user to customize

the system
settings,
ensuring
optimal performance when using the system.

Multiplayer Functionality

Finally, the system will provide a multiplayer environment, allowing the user to connect and compete

with other uses
running the software.

The results of other users


performances will be displayed for all use
r
s competing to view.



gp08
-
nhn

Dr. Henrik Nilsson

Page
9

of
62



Research




gp08
-
nhn

Dr. Henrik Nilsson

Page
10

of
62


RESEARCH

Existing Systems

While performing research, it was seen that most musical/rhythm based
system/
games currently available could be divided
into three sections:



Console video games



Online role playing games



Flash/Applet based systems

The research performed analyzed each of the different categories and the multiple software solutions that can be found
within them. Below is

a brief description o
f each category, as well as details about the functionality and relevance they
provide.

Consol e Video Games

Musically based games within this category tend to focus on the multiplayer aspect of game play. This can range from
multipl
e users playing in the s
ame location in a co
-
operative
style
manner
(1)

to users connecting online and playing against
other users with compatible software

(2)
.

They generally focus on the entertainment aspect of
game play rather than having
educational aspiration
s

(3)
.

Guitar Hero


DESCRIPTION


Guitar Hero


(4)

is a game in which experience is everything.

The game is played by

users performing songs on a guitar
shaped peripheral,

matching
the colours shown on the interface
,

with those represented physically on the guitar.

It
supports

both

single player and multiplayer modes

and incorporates a range of licensed and independent m
usical tracks
dating from the 1960’s to present day.


gp08
-
nhn

Dr. Henrik Nilsson

Page
11

of
62


ANALYSIS

The main focus of this system is the entertainment aspect of the game play, with rela
tively no educational influence,
allowing the user

to focus only on enjoying the game. This is further enhanced by the fact that the design and
implementation of the system is simple, allowing a wide range of audience to be able to experience and enjoy playing the
game.

Guitar Hero will be a starting poin
t from which the system being developed will evolve.

Online Rol e Playing Games

Role p
laying games are usually defined

as games in which a user controls an avatar inside a virtual world. The games within
this section combine a virtual society with sub
-
games

(in this case musically based

(5)
) which are of relatively higher quality
than flash/applet games. These systems neither focus on an educationally motivated structure nor a multiplayer one in the
traditional sense. Instead
they implement a scoring/
levelling

system which helps increase the level of the player’s avatar

(6)
,
provi
ding

motivation to continually play the game.

Burst a Fever


DESCRIPTION


Burst a Fever’

(7)

is a Chinese game which uses a standard computer keyboard. One hand is assigned to the letters s, d and f
and the other is assigned the letters j, k and l. The game is played by pressing the letter when the corresponding note
reaches the bottom of the scre
en.

ANALYSIS

The fast paced speed of the game combined with the detailed graphics makes this an addictive game to play. However, the
speed of the game is only possible because of the limited number of keys the user has to press. Given more keys it would
b
e impossible to play the game at some of the speeds available.

Due to the intensity of the game, the learning curve is higher than that of the other games. This is advantageous in that it
allows for a more intensive experience for users who are accustomed
to this type of game. However, it also has the
disadvantage that this may exclude other users who may be intimidated by the amount of features provided
,
reducing the
size of the core audience.



gp08
-
nhn

Dr. Henrik Nilsson

Page
12

of
62


Flash/Appl et

Systems

This is a popular category due to the fa
ct that the games
/systems

are often free

(8)

and small in size

(9)
, while still proving
the user with a new level of interactivity. The attraction also comes from the fact that the games are often
quick and
simple, with a relatively small learning curve, giving users of different technical backgrounds the opportunity to experience

the functionality of the system.

Although not technically a game
, ‘Piano Machine’

(10)

is a

useful example which demonstrates the functionality provided by
this type of system.

Piano Machine


DESCRIPTION


Piano Machine
’ provides the user with a virtual keyboard on which they can play a set of keys. The notes that are pressed
are then added to a

sheet of music which can ei
ther be played

or dynamically changed using the mouse. This not only
allows the user to see what they are doing, but also sho
ws how the keys relate to music being played.


ANALYSIS


Piano machine’

is a prime example of a flash/a
pplet based application. It is free and small while still providing a level of
functionality which many users will find extremely useful. The uncluttered and simplistic design enhances the user
experience and ensures that the learning curve is hardly notic
ed at all.

However, a notable feature missing from the system is the ability to store or save the sequence of notes. This would ad
d a
level of functionality that

would allow users to return and continue using the system.

Research Overvi ew

Every category m
entioned in the research has benefit
s and drawbacks. Therefore, an was

made to amalgamate all the
benefits of existing systems, with
the feature of the system
developed. However, it is essential that in doing this the
shortc
omings o
f these other systems we
re

not transferred to the system when implementation
occur
red
.



gp08
-
nhn

Dr. Henrik Nilsson

Page
13

of
62


Musical Interfaces

Music can be digitally rep
resented in many different ways, such as sample audio or by using

the

Musical Instrument Digital
Interface

(11)
.


S
ampled audio

produces music by extracting information from
analog
ue

signals

and converting these signals

to a digital
format which can be played
. This form of representation is not relevant to
the scope of the project

but is often mentioned
in conjunction with MIDI
.

Therefore to avoid confusion, the MIDI specification that will be the focus of the system is
detailed below.

Musical Instrument Di gital Interface (MIDI )

MIDI is a
n industry

standard protocol

(12)

which allows for communication between electronic music devices

(13)
.

There is a
general misconception about how musical data is represented digitally.
It is assumed that the data

contains the ac
tual
sound of the song.
This may be true
in
some specifications, h
owever

in
MIDI;

the data stored only contains the
r
epresentation of the sound
(14)
. This

data

is then processed to produce the actual sound heard via output devices such as
speakers.

The diagram above is a high level representation of the process of converting musical data represented as
MIDI to audible output. Outputting the data as audio is not the only option available; however for the scope of
this project,
it is the most
relevant area
.

Why Use MIDI

MIDI
allows devices to connect,

communicate and transmit data electronically

using MIDI Messages
. It also specifies a file
format for

storing
these
messages

(
Standard MIDI Files
)

(15)
.

Using
MIDI

is an effective and efficient way of representing musical data and h
as various benefits

(16)
:



It can reduce the file size of a song as only the representation of the notes are
stored



The quality of the output is dependent on

the devices abilities

to perform the messages

(
rather than on the way in
which the data was stored
)



Individual pieces of data within a MIDI file can be changed
, al
lowing for specific corrections/changes
within a song

to occur, without affecting the entire song.



Data within a file can be played with any instrument

allowing for a large scope of creativity when creating music



The entire MIDI file can be changed

(e.g. changing tempo)

so the musical data is processed diffe
rently
.

However it also has various drawbacks:



The data held in the file has to be processed at runtime, this means that extra processing time is required



The extra processing can consume more power which can be a problem for mobile devices



Music
r
epresented
d
igitally

Musical data is
processed

Sound is produced
using an output
device

gp08
-
nhn

Dr. Henrik Nilsson

Page
14

of
62


MIDI
Messages

As briefly stated above, a MIDI Message contains information which is sent between MIDI compatible devices and systems.
These messages contain specific information which allows a device or system to interpret the data contained within the
messages and per
form some action based on what is being represented.

In the MIDI specification a
MIDI

message is
usually
composed of

a
sequence

of bytes (usually three, but can be less in
certain cases). The
diagram below describes a typical MIDI message
template

which c
o
nsist
s

of, a single status byte,
followed by two data bytes.


The status byte of the message informs the receiving device as to what the message
contains. The

data byte/s
contains

the information relating to the specific type of message being sent.

Message Types

MIDI Messages can be

divides into two subgroups, MIDI Channel Messages and MIDI System Messages. Channel Messages
deal with message which are specific to certain area (see channel description below), while System Mes
sages are used to
provide a

message which is more global to
the system.

T
he diagram below shows the hierarchical structure of the messages

(17)
.



MIDI Channel Messages and MIDI System Messages are a subgroup of MIDI Messages and each serve a
specific purpose.


For the purpose of
this report (and brevity), only MIDI Voice Messages will be analyzed in detail
. However a complete
explanation of the other messages can be found in the MIDI specification
(11)
.

MIDI
Messages

Channel
Messages

Voice
Messages

Mode
Messages

System
Messages

Common
Messages

Real Time
Messages

Exclusive
Messages

Midi Message

Status Byte

Data Byte

Data Byte

gp08
-
nhn

Dr. Henrik Nilsson

Page
15

of
62


Channels

MIDI channels can be defined as a
route on which MIDI messages can be transferred. There are 16 different MIDI channels
available (usually numbered 1
-

16). This is important because it means that each channel can be used to represent used to
represent the MIDI data differently (e.g. each
channel represents a different instrument).



1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16




Voice Messages

Voice Messages

(18)

are a subgroup of Channel Messages and are therefore used to hold data about a certain event being
sent along a specific channel.

Messages within this category have various functions. They are used to inform devices about which particular sound should
be

played. They

can also

specify when a certain note has been activated or deactivated (e.g. a key being pressed and
released on a keyboard)

and can also alter notes which are currently being played.

The two messages that are of most importance are ‘Note On’

and ‘Note Off’. These are the only messages mentioned in
this
section;

however the MIDI specification should be consulted for further analysis

of other messages (if needed)
.

Note On


Note Off

Note on and note off are two different events which represent

when a specific musical note has been activated and
deactivated (e.g. when a keyboard key is pressed then released).

They use the same template convention previously
describe (one status b
yte followed by two data bytes).

H
owever these bytes are now filled

with
the following
spe
cific note
information:



Channel specifies the route on which the MIDI message must be sent



Note number contains information about which note has been
activated

(on a keyboard this would represent a
single key)



Velocity stores how
hard the user has played a given note (how hard a

key was pressed on a keyboard)


When a n
ote
o
n message is sent, the status byte contains the number on which the note must be transmitted. The other
two data bytes contain the key number and the velocity. A
n
ote
o
ff message consists of the same
data;

however the
velocity stored contains the released velocity.

It is important to note that
n
ote
o
ff is rarely used
,

as a release
d note can be
represented as n
ote
o
n message with a velocity of zero.

Channel

Note Number

Velocity

Note On/Note Off Message

Device

MIDI

Message

Device

MIDI

Message

Channels

gp08
-
nhn

Dr. Henrik Nilsson

Page
16

of
62


MIDI Fil e Format

MIDI messages can be grouped with timing i
nformation which is then stored in a file system. The MIDI specification gives a
formal description of a Standard MIDI File (SMF). These files consist of MIDI messages which are organized into parallel
tracks which can usually be associated
with channels.

There are three different types of SMF file structures.



Format 0 contains a single track and represents a single performance



Format 1 contains multiple tracks
but still represents

a single song performance



Format 2 contains multiple tracks with each track

representing a separate song performance

MIDI Sequencer
s and MI DI Synthesizers

A
MIDI

sequencer allows

a

MIDI
Sequence (see below)

to be captu
red, edited or stored

before being
passed

on to

the
synthesizer where the sequence would be played through output

devices (speakers)
.


However, the

synthesizer does not require a sequencer to play a MIDI sequence. The Sequencer
is used when the data
being passed
,

needs to be altered/viewed.

What is a Sequence?

A sequence is used

to represent a series of MIDI E
vents,
which consist of MIDI messages and a time stamping attribute.
The
diagram below is used to represent this. However it contains only a single track, it can
(
as specified by the MIDI File Format
)

contain multiple tracks.


Note: A time stamp is a piece of data which stores details about when the event occurred relative to a given time. It is usef
ul
for tracking events.


Sequence

Track

MIDI Message

Time stamp

gp08
-
nhn

Dr. Henrik Nilsson

Page
17

of
62



Requirement

Specification



gp08
-
nhn

Dr. Henrik Nilsson

Page
18

of
62


REQUIREMENT SPECIFIC
ATION

Introduction

System Overview

The system will be a software
-
based solution providing users with the ability to play MIDI songs via an external keyboard. It
will provide a graphical user interface, which
display information about the song and the notes which will be played by the
user. The system should also be dynamic in that it will allow users to upload a compatible song. Finally the system will have

a multiplayer aspect, allowing users to connect to ot
her users running the software.

Users

The software should appeal to a wide range of audiences; however the main focus will be on the beginner to intermediate
group, with respect to thei
r level of musical experience.
However, there is scope to increase this

to higher level of
experience.

Assumptions

It is assumed that the following requirements are met by the user:

1.

The user has a keyboard which is capable of MIDI output and is capable of being connected to the computer using
a form of MIDI interface (e.g.
USB or MIDI cable)

2.

The user has at least version 1.6 of the Java Runtime Environment

3.

The equipment running the system should have a screen no smaller than 640 x 480

4.

For multiplayer functionality, the user must have access to a suitable internet connection

5.

The environment running the system includes some form of audio output device

System Requirements

Functional Requirements

Detailed below are lists of verifiable and testable requirements provided by the system:

Midi Requirements

The systems should:



Be able
to detect and list all currently connected MIDI devices



Allow the user to select which MIDI device they would like to use



Deal with opening and closing connections to the selected device



Receive any data that is sent from the MIDI device



Allow the user to
load a specified MIDI file



Gather and store information found in a standard MIDI file



Compare the MIDI device output with the MIDI file data using a comparison algorithm



Process all MIDI data and provide aural feedback through some form of output device



gp08
-
nhn

Dr. Henrik Nilsson

Page
19

of
62


User Interface Requirements

The graphical user interface should:

1.

Display a range of songs that
the
user can choose from according to
the
user
s

level

2.

Dynamically display the notes from the song which are currently meant to be played

3.

Provide a representation

of a keyboard showing users which key to press

4.

Identify
a
key wh
en

it
is pressed on the keyboard

5.

Display in some way how long a key is pressed on the keyboard

6.

Report how hard the user presses a certain key

(velocity)

7.

Have a simplistic design with a smal
l learning curve

8.

Fit a screen size of no smaller than 640x480

9.

Scale to larger screen size based on user preferences

10.

Display information about the song currently being played (e.g. name, tempo and length)

11.

Display information about the user (e.g. name,
score, level)

12.

Provide feedback on how well the user is playing a given song

13.

Provide the user with a settings dialog for customization (e.g. preferred language, volume or theme)

14.

Have a section where the user can review the game rules

Game Requirements

The g
ame should:

1.

Provide a scoring system which uses the data
provided
to generate scores for the user

2.

Allow users to compare their own performance scores against other players

3.

Let users access only songs which are suitable to their level

4.

Allow users to access
higher levels once they have increased their level

5.

At the end of end level the system should display game statistics (e.g. score, level)

Communication

The
systems communication functionality with the server should:

1.

Notify and retrieve new MIDI files which
are provided

2.

Retrieve information about other users’ best scores

3.

Update the score of the user once a level has been completed

4.

Populate a list of currently active clients and retrieve their addresses

The systems communication functionality with other
clients should:

5.

Allow users to connect and exchange information about their performances

Non
-
Functional Requi rements

Operational

The system should be platform independent able to run on commonly used personal computers

Performance

The sequence of notes mus
t be synchronized and should display and play on the graphical user interface and output
device (respectively)

gp08
-
nhn

Dr. Henrik Nilsson

Page
20

of
62


Security

1.

A user should not be able to affect the scoring within the system

2.

Data held on the server should only be able to be modified by the
system

Cultural and Political

The system should allow for internationalism through different languages (e.g. English or French)




gp08
-
nhn

Dr. Henrik Nilsson

Page
21

of
62



System

Design



gp08
-
nhn

Dr. Henrik Nilsson

Page
22

of
62


INITIAL DESIGN

System Design

The initial design involved three different
modules

working together to produce the system. This modularity allows for an
object oriented approach to be used when implementing the system. As the components are modular, they can easily be
replaced by other implementations as long as they allow for the same
set of features and functionality as the component
they are replacing.

Diagramming
Convention
s

In the diagrams that follow the following conventions are followed:


Context

Diagram

Below is a context diagram for the system:


The diagram above shows a high level structure of the system. The two

user entities
represent
how
users
will interact

with
the system. In this instance the user entity on the left

(User
1
)

of the diagram represents

the
us
er currently using the system.
While the users on the right of the diagram

(User
*
)

represent other users to which the user on the left would connect i
f
multiplayer mode was enabled.

User
1

0

System

User
*

Ref Number

Name



危u慲e⁢o硥V⁲epreVen琠e硴ern慬aen瑩W楥V




副RnTeT bo硥V 牥p牥Ven琠moTu汥VH w楴i 愠牥fe牥nce number
楮⁴Ue⁴op⁳ 捴楯n⁡nT⁴Ue慭af⁴Ue moTu汥⁩ ⁴Ue⁢o瑴om
Ve捴楯n



副RnTeT

T慳桥a

bo硥V⁲ep牥Ven琠
VyV瑥mIV




䅲牯wV 牥preVen琠 慣a楯iV o爠 T慴a 捯浭un楣慴楮朠 be瑷Wen
瑨e⁳祳瑥mIV

gp08
-
nhn

Dr. Henrik Nilsson

Page
23

of
62


Level 0 Diagram

This level 0 diagram shows how the user communicates with
the client application

and how the modules communicate with
each other.
The user mainly interacts with Game module with exception, when the midi keyboard is used, in which case the
Midi module processes the request directly.

The client applications are com
municating with each other through their
Connection modules, thus
the users can communicate indirectly with each other.


Level 1 Diagram

The following section contains a description about each module contained within the system. The diagrams are used to
provide a general overview of t
he processes which occur within each module.

Game Module

The Game module is used to handle the requests of the user and to transfer these requests to the appropriate modules.
This request is either made by clicking on the menu of the game or by pressing
the appropriate shortcut key on the
computer keyboard.




Game

Process Request

MIDI

GUI

Connection

User Requests

User
1

2

MIDI

1

Game

Proces

4

Connection

3

GUI

User
*

2

MIDI

1

Game

Proces

4

Connection

3

GUI

1

*

gp08
-
nhn

Dr. Henrik Nilsson

Page
24

of
62


GUI Module

The GUI module is
created

from two parts
.

T
he first part

deals with the interface

outside
of the main drawing
canvas by
displaying dialogs of the main window. After the request had been processed, the
appropriate

dialog is going to be shown
to

the user.

The second part of this module creates the graphical objects on the canvas at the centre of the main window. At each loop,
the state of the game will be processed and the appropriate elements will be drawn ac
cording to the information received
from the game module.

MIDI Module

The MIDI module

contains all the MDI functionality required within the system.
It process
es

a given MIDI file
and input
from the user via a MIDI device. One channel from the MIDI file wi
ll be passed to the comparison algorithm (see below)
along with the MIDI input. This will be used to generate a score. Once this is completed the data will be passed on to the
synthesizer where it will be processes and passed to the relevant output device
(speakers).


MIDI File

Sequencer

Synthesizer


Output
Device

Comparison
Algorithm

-

Receiver

-

Transmitter

Process

Channel 1

Channel


2
-
16

MIDI Channel

MIDI Device

Dialogs

Dialog Request

Handle Request

Screen

Game State

Graphics

Update Game Details (score, level)

Update Sequence Notes

Dynamically Change Keyboard

Canvas

Drawing


Drawing

Drawing

Screen

gp08
-
nhn

Dr. Henrik Nilsson

Page
25

of
62


Connection Module

This module deals with the communications between different computers. It includes establishing a connection to the
server by sending a request and receiving the answer for the request.

It allows

the sy
stem to establish
connection
s

to other clients and receive

this kind of connections as well. The server will
never initiate a connection to a client; hence it remains the task of the client. Before a client can make a connection to th
e
other clients, it wi
ll have to ask the server about the addresses of the other clients. The server will store the address of the
client at each request and will transmit this address to the other clients when they request it.

Once these addresses are known by the clients, t
hey will establish connections among them
selves. With each user either
performing the purpose of a server or a client
,

within

in this client to client network, hence each client has a direct
connection to the other clients, which will remain open until the

end of the game.






Initial Request

Update
Request

(Every 5mins)

Score Update
Request

Top
L
ist
Request

Game State
1

Co
nnection

Server

Request to Server

Store Information

Check and Process

Send Request

Update Other
Clients

Process

Store Info

Game State
*

Process Request

Store Data

Process Request

Other Clients
Information

Best Scores

Process

Dialog Request

1

*

gp08
-
nhn

Dr. Henrik Nilsson

Page
26

of
62


Comparison Algorithm

T
he following
section contains a
brief overview
and explanation
of the initial design for the comparison algorithm used
within the MIDI module. It is used to compare the MIDI data received from t
he MIDI device
within the MIDI data
contained
within a specified file
.

Overview

TODO:



gp08
-
nhn

Dr. Henrik Nilsson

Page
27

of
62


Graphical User Interface

Introduction

It is widely agreed that human computer interface is of critical importance in a software system.

The
scope in designing the
Graphical User Interface (GUI) is to make it useful and accessible for a large section of the public by ensuring that the gam
e
is approachable, enjoyable and attractive.

Overview

The GUI is split into
three

separate sections
, the menu bar, the game canvas
and the status bar.

The first section is the menu bar:



Contains general options which allow the user to perform various functions within the game. This includes but is not
limited to starting a new game, choosing the default language, viewing the high scor
e, viewing the help or quitting the
application.

The second section is the game canvas which is split into three sections:



The top section provides context sensitive information about the game currently being played. For instance, it will
include game data

(score, level), player data (players’ name) and MIDI data (song name, duration). Additionally, for the
multi
-
player functionality, it will display a top list of the highest achieving players for a given song.



The middle section consists of falling rectang
les which are used to represent the notes which must be played by the
user on the MIDI keyboard. These rectangles vary depending on various aspects of the note, for example, a notes
length (how long it should be played for) is given by the length of the re
ctangle. The middle section also relays
feedback about their performance for a given note.



The bottom section of the canvas holds a representational keyboard, which allows the user to see where the notes
should be played. The keyboard is dynamically drawin
g and changes size according to the size of keyboard used by the
player.

The third section contains a status bar:



I
nforms the user about changes to system and functions in a similar way to a web browsers status bar. For instance it
can inform the user when

a MIDI device is not connected.



gp08
-
nhn

Dr. Henrik Nilsson

Page
28

of
62


Diagram

The diagram below is a representation of what was detailed above.


Future Revi sions

The
diagram

was just a basic prop
osal for the system; therefore was

scope for further improvements in later revisions of
the system.

For the final versio
n, there is scope for the possibility
o
f

incorporating
a
m
ulti
-
screen interface.
This would allow for
different screens to divide the game into multiple sections, such as “
Welcome screen”
, “S
ingle

Player”

or
“Multip
l
ayer”.
There would also be sections for
looking at instructions, viewing the highest scores, choosing the level, the song or the
album.

Another improvement

which could be implemented is an
on
-
line interface corresponding
to

a multi
-
player game.
It would
allow the user the o
pportunity of choosing

a name, recording their performances, seeing the score for the others and their
position in the top

list
.


Player Data


MIDI Data

Representational Keyboard

Falling
Note



Menu Bar




(Multi)Player Data



C

D

Status

Bar

gp08
-
nhn

Dr. Henrik Nilsson

Page
29

of
62



Implementation



gp08
-
nhn

Dr. Henrik Nilsson

Page
30

of
62


IMPLEMENTATION

Implementation Decisions

The purpose of this part of the report is to give an overview of the key implementation
decisions made by the group and
the affect that this has made on the development of the prototype.

Programming language:

Within the project there will be two programming languages used,
the section below details the reason for choosing them
and
why they wi
ll be used.

Java

During a group discussion it was decided that the main programming language that will be used in the development of the
system will be Java.

The main reasons for this are:



Java is cross
-
platform, allowing the system to reach a wider audien
ce



JRE has relevant functionalities to the project, which will aid in the development process; including:

o

MIDI handling (JAVA
Sound)

o

Sound generation (JAVA
Sound)

o

GUI programming (Swing)



It also has an excellent user base and support group

Additional
reasons:



Java is used for various real
-
world applications and provides access to various useful free libraries

Note: During the development of the application JDK 6 (version 1.6) will be used as there are some used features which are
not included in
previous versions.

Java will be used to develop the client part of the system and will be responsible for communicating with user, handling the
midi interaction, dealing with the game theory
,

and later on communicating with other clients.

PHP

PHP will be r
esponsible for

performing various functions, such as
storing the score results received from the clients
,

detailing
update possibilities
f
or

the game version

and provide a hub
-
like service where

clients can find each other.

The
server part of the software
is a one
-
man
-
required task and it is going to be written in PHP.
The reason for this decision is
that this way the server module can be handled by a web server, and PHP is a commonly used web
-
based programming
language.

Operating systems:

The application w
ill be
implemented in a
cross
-
platform
manner
, and will be tested on different operating systems
including Windows

(
XP SP2
, XP SP3
, XP x64 SP2
, Vista
)
,
Mac
OS X

(version
10.5

“Leopard”
)

and Linux

(Ubuntu

7.10 “
Gutsy
Gibbon

, 8.10 “
Intrepid Ibex


x64
)
. This

way this piece of software can be available for a wide range of users. For the base
game, the presence of JRE 6 is enough, but for the OpenGL it would require an operating system supported by JOGL.

Hardware:

A MIDI keyboard will be required to be connecte
d to the computer and their drivers to be appropriately installed. The
minimum required computer specificatio
n is not yet determined, but the system
should not require a
n overly

powerful

computer to be able to use the program.

gp08
-
nhn

Dr. Henrik Nilsson

Page
31

of
62


Software:

The solution will
provide the programmers with the ability to develop for either Swing or OpenGL as a graphical renderer. In
the final program it was decided to implement only the Swing version.

The OpenGL

would provide the game with the ability to appear more attractive an
d
this is its main purpose

that the ability
to program with it has been implemented.
For the users to be able to use this version of the graphical renderer, they will be
required to have OpenGL inst
alled on their operating system. Additionally to the main
OpenGL they will require to have a
working JOGL on their system as well.
JOGL is a wrapper which allows for OpenGL to be used within the JAVA programming
language. However for the initial prototype development, the focus of the development will be implemen
ting Swing

For the server functionality, the software used will require version 4 (or higher) of a PHP enabled web server.
The server
will communicate with client through

HTTP.

Classes

This section describes the plan of the classes, their communicati
on, th
eir main purpose and the

key implementation idea.


gp08
-
nhn

Dr. Henrik Nilsson

Page
32

of
62


MAIN CLASSES:

This

module deals with the initializations, the main loop, and any closure procedures. The other modules
are
connected to
this module

which provides communication between them
.



Keyboard Hero

-

This class implements the main frame (window) of the application, contains the main method and
starts the loop of the game.



Game

-

This class is the main communication hub between the classes, and it also handles the rules of the game. This
class reques
ts information from MIDI classes, and stores the current state of the game, which is then passed on to the
Graphs class.

MIDI CLASSES:

This module handl
es the functions and operations which are needed
to

be able to use

MIDI devices and

MIDI
files.



MIDISong

-

This class will deal with MIDI files. It should allow the system to open and read a specified MIDI file. It
should also gather any information about the file it can (such as Meta details) and parse the file for MIDI messages.



Device

-

Any interaction
with external MIDI Devices will be dealt with by this class. It will list currently available MIDI
devices and open and close connection to a specified device. It should also be able to deal with any messages which
may be sent from the device



MIDISequencer

-

The sequencer will be the main class within the MIDI section. It deals with both the file and the
device class. Getting input from both, and comparing a single channel of the file input with the input coming from the
device class. It also passes along a
ny the data to the synthesizer.



MIDISynthesizer

-

Any events which are received from the sequencer will be played aurally here through available
output devices (speakers). This include the MIDI device output and all channels from the MIDI file

GUI CLASSES:

The main role of this module is to handle the Graphical User Interface inside the main window.



Graphs

-

This class makes the representation of the graphical objects on the canvas. It organizes and locates these
objects. It draws them by using one of the G
raph Renderers.



GraphRenderer

-

It provides an interface for all the possible renderers.



RendererSwing

-

This renderer uses only methods which are included in the standard JRE.



RendererOpenGL

-

This renderer uses external libraries, so it can make method
calls to the OpenGL.



DialogRules

-

This dialog shows the rules of the game. This is done by displaying an HTML document.



DialogSettings

-

This is a dialog, which contains the possible preferences of the program. Options encountered so far:
how many keys on

the keyboard; preferences of the full
-
screen mode; communication server, proxy, name of player. It
will passes these information to the Util, where it is available to the other classes.



DialogTopList

-

This dialog shows the best players of the game. This
class used for both the local and online score lists.

CONNECTION CLASS:

This class handles the communication with other computers
. This included

the server and client

architecture and
application

of the game.



Connection

-

This class handles the connections

with the server and with other clients. Asks the server for possible
updates, for the online score list, and a list of the current clients. Also exchanges information with other clients about
the performance of the active player.

GENERAL CLASSES:

gp08
-
nhn

Dr. Henrik Nilsson

Page
33

of
62


These
classes may be used by any other classes in the package, because they provide general functionalities.



Util

-

It provides utility methods (including file handling, error handling), stores the settings of the application, and
reads in the text messages
(according to the selected language).



Tester

-

Provides testing and debugging functions and makes it possible to create unit tests.



gp08
-
nhn

Dr. Henrik Nilsson

Page
34

of
62


Graphical
User Interface

Introduction

The graphical user interface for the final program is based on the initial design. I
t is implemented using Swing and was
created by prototyping. However, there are modifications to the initial design which provide new features and
functionality.

Impl ementation

The interface is composed of various sections (as described in the initial des
ign), consisting of the menu bar, the status bar
and the game panel


which is then also split into various sections.