*** empty log message ***

diff --git a/report.txt b/report.txt
index f1e1e3bdaf893b067cc048199d363ddfdbd61bdf..34822770e7ed6ff2f96dcd4020ed701d79029afa 100644 (file)
--- a/report.txt
+++ b/report.txt
@@ -2,46 +2,48 @@ Foreword (optional)
 \r
 OBS! [...] = Hjälp till om ni kan och lägg in text\r
 \r
-Introduction\r
+1. Introduction\r
 \r
 The main goal with our project was to design and construct a midi-software developing program.\r
 Both for arranging and playing already existing midi-files, and for composing and saving midi-files from scratch.\r
 We chose this project for mainly two reasons. First, noone of us had previous experience of working with music in the Java language, so this would be a great challenge. Second, we are all quite interested in music.\r
 \r
-Analysis\r
+2. Analysis\r
 -----------------------------\r
-< Java Soundpackage >\r
+2.1 Java Soundpackage\r
 Our first step was to look at the Java Soundpackage, and to try to find out what limits the package had. Noone of us was familiar with the package and wanted to get an overview before we started working with the design document. We also had to look at some software that supported midi to get an idea what features our application might have.\r
 -----------------------------\r
-< Design Document >\r
+2.2 Design Document \r
 We realeased were quickly that most of the classes we had to construct was associated with the interface. We divided the program into two major parts. The main part, the actual program, included four functional classes. Our starting point was to make one class including the 'main method', we gave this class the name Moosique (an combination of moose and music). \r
 \r
 Under the Moosique class we designed three classes that modifies different parts of an midi-file. \r
 MooSequence [...], MooTrack [...] and MooNote [...]. \r
 \r
-The second part of the program includes the graphical classes. The top-class of the interface is a class called MooGUI that [...]. Under the interface top-class MooGUI we designed some graphics classes that constructs a menu, a statusbar and a toolbar. All these classes [...]. \r
+The second part of the program includes the graphical classes. The top-class of the interface is a class called MooGUI that [...]. Under the interface top-class MooGUI we designed some graphical classes that constructs a menu, a statusbar and a toolbar. All these classes [...]. \r
 \r
-Beside the strictly graphical classes we decided to make graphical representation of the functional classes, this to get an better overview of our work [...]. MooView (an graphical representation of MooSequence), MooTrackView (MooTrack) and MooNoteElement (MooNote). To support these files some other graphical had to be designed. MooViewCounter represents an ruler that shows the [einar], MooTrackTitle handles the properties of one track and MooNoteElement the properties of one note.\r
+Beside the strictly graphical classes we decided to make a graphical representation of the functional classes, this to get an better overview of our work [...]. MooView (an graphical representation of MooSequence), MooTrackView (MooTrack) and MooNoteElement (MooNote). To support these files some other graphical classes had to be designed. MooViewCounter represents an ruler that shows the timesignature of the midi-file, MooTrackTitle handles the properties of one track and MooNoteElement the properties of one note.\r
 \r
 We constructed this design document very quickly, maybe to quickly. We werent really clear how some of the functions in the Java Soundpackage worked. Later in the project we were forced to change what we earlier had planned, se section [Major Decissions]. \r
 ------------------------------\r
-< Time Schedule >\r
-Before we started to implement the code we made an time-schedule for each class, and divided the classes between us. Later we realeased that for a few classes this time-schedule were very optimistic. The consequences of a misleading time-schedule were that some classes was not implemented before a very long time in the project [mer?].\r
+2.3 Time Schedule\r
+Before we started to implement the code we made an time-schedule for each class, and divided the classes between us. Later we realeased that for a few classes this time-schedule were very optimistic. The consequences of a misleading time-schedule were that some classes was not implemented before a very long time in the project.\r
 ------------------------------\r
-< Implemention >\r
-       Functional classes [...]\r
+2.4 Implemention\r
+As we earlier realised we needed to implement the functional classes first. This to see what references the graphical representation might call. [...]\r
        Strictly graphical classes [...]\r
 ------------------------------\r
-< Major Decissions >\r
+2.5 Testing\r
+------------------------------\r
+2.6 Major Decissions\r
 [...]\r
 ------------------------------\r
-< Problems >\r
+2.7 Problems\r
 [...]\r
 ------------------------------\r
-Conclusions\r
+3. Conclusions\r
 \r
 \r
-References\r
+4. References\r
 FastTracker II\r
 MidiSoft Recording Session\r
 CakeWalk 5\r