+We put the application's design document together very quickly, perhaps a bit too quickly. We were not entirely certain of how the Java MIDI package worked. As our work with the project progressed, we were forced to reevaluate some of these design decisions and change the system design (see section [Major Decissions]). On the other hand, our interface design has barely needed any changes.\r
+------------------------------\r
+2.3 Time Schedule\r
+Before we started implementing the classes, we made a time schedule for each class and divided the classes between us. Later on, we realized that for some classes this time schedule was overly optimistic. As a consequence of these misconceptions, some of the classes were not implemented until the very last stages of the project.
+
+The schedule that was made initially reflected the time required to implement the functionality of which we then knew. However, as time went on, the complexity of building this type of application became apparent and all our time estimates were by far exceeded. Also, many minor details were changed or for other reasons reimplemented, which of course took a lot of time.\r
+------------------------------\r
+2.4 Implemention\r
+As we earlier realized, some implementation of the functional classes was required to see what features the graphical representations would need.
+
+As an indication of which classes that were most difficult to implement, the version numbering of the Concurrent Versions System can be compared. In that respect, the most frequently altered classes were MooTrackView, Moosique and MooToolbar.
+
+[...]\r
+
+Strictly graphical classes [...]\r
+------------------------------\r
+2.5 Testing\r
+Är det nån som har testat nåt dårå?!?
+------------------------------\r
+2.6 Major Decisions\r
+
+2.6.1 Removing some of the functional classes
+Initially, the idea behind the functional classes - MooSequence, MooTrack and MooNote - was that they would extend the classes provided by the Java MIDI API and provide additional functionality for simplifying data manipulation. Soon however, it was discovered that this was not possible because of the methods related to these classes in the API. It was then decided that these classes would imitate the data hierarchy of the MIDI file, as the Java classes do, but provide their own implementations. When the edited sequence was to be sent to the synthesizer for playback, the data would be assembled and inserted into the Java classes. At a later stage, this design was also scrapped, the reason being that creating and maintaining such a data structure would require more code than using the somewhat limited methods of the API. MooSequence and MooTrack was therefore removed.\r
+
+2.6.2 Adding and removing some of the GUI classes
+As this was the first time for all of us in designing an application before implementation, we were not able to predict exactly which classes would be required. During the course of the project, the following classes were added:
+x MooDialog A dialog generator class for all the application's dialogs.
+x MooInstrumentList A combo box with the 128 General MIDI instruments.
+x MooKeyboard A keyboard listener emulating a synthesizer.
+
+One class, MooStatus, was also removed. It was reduced to a JLabel with a single method and was therefore merged inte the main GUI class.
+------------------------------\r
+2.7 Problems\r
+Of all the problems we have come across in our work with Moosique, only one has persisted and is yet unresolved. As always when working with Java, we were aware that the visualisation performance leaves more to be desired. But we did not expect the extremely low performance the program displayed. During playback, a thread updates the view port of the main scroll pane (MooView). However, the update delay on low-end hardware exceeds one second. This obviously makes the GUI unresponsive, but also affects synthesizer playback performance. In order for the application to work properly, this delay must at the very least fall below the time it takes the synthesizer to play a sixteenth note. In a sequence of standard tempo, 120 beats per minute, this would mean 1/8 of a second.
+
+This problem is especially unfortunate since it was the only performance aspect that was mentioned in the requirements specification.
+
+[Ändra font och dra ner textstorlek, citat juh!]
+"Delays during execution should be minimized, but are allowed when loading files. Playback should be smooth and delays should not change the beat or tempo."
+------------------------------\r
+3. Conclusions\r
+During the course of this project, the importance of extensive system design has become clear to us. With no prior experience in writing such documents or with working with the API in question, designing every aspect of our application would have been nearly impossible without at least approaching the implementation phase. In the future, our proficiency in this field will hopefully improve drastically, and we will be able to save a lot of implementation time by writing more complete design documentation.\r