report.txt

   1 Foreword (optional)
   2
   3 OBS! [...] = Hjälp till om ni kan och lägg in text
   4
   5 1. Introduction
   6
   7 The purpose of our project was to design and construct a composer's tool for the MIDI interface. The program was to be used for composing and sequencing MIDI songs from scratch, as well as for playback and visualisation of existing MIDI files. We chose this project for two reasons. Firstly, none of us had previous experience of working with music in the Java language, so the task of developing an application using an API with which we had no previous experience was challenging. Secondly, we are all very interested in music. One of the developers is also an experienced MIDI composer.
   8
   9 The MIDI application we were going to develop was at an early stage given the name Moosique - a name obviously derived from the word music, but with a touch of moose.
  10
  11 2. Analysis
  12 -----------------------------
  13 2.1 The Java MIDI Package
  14 Our first step was to look at the Java MIDI package (javax.sound.midi), and to try to find out what limitations the package had. As previously stated, none of us was familiar with the package and we all wanted to get an overview before we started working on the design document. And it didn't take long to realize that the functionality and structure of our application were largely dictated by the possibilities provided by the MIDI package. We also looked at software that supported MIDI to get an idea of which features our application might have.
  15 -----------------------------
  16 2.2 Design Document
  17 One of the first design decisions that was made was to divide the program into two major parts. The main part, the classes providing the actual features of the program, included four functional classes. The executable class, the only one containing a main method, was given the same name as the program - Moosique.
  18
  19 In a hierarchy below the Moosique class, we placed three classes that represented the different parts of a MIDI file:
  20 x MooSequence   The functional representation of a MIDI sequence. Was to extend Java's Sequence class.
  21 x MooTrack      The functional representation of a MIDI track. Was to extend Java's Track class.
  22 x MooNote       The functional representation of a MIDI note. Was to encompass the two MIDI events that constitute a note: NoteOn and NoteOff.
  23
  24 The second part of the program was the graphical user interface, including all the graphical classes. The main class of the interface was named MooGUI. Since we had decided to use Swing in building the interface, this class was naturally to extend JFrame. Here, all other GUI components were to be created. Most of these components - maintaining different kinds of data, having listeners and requiring different methods for update their content - were to be quite complex, and were therefore given their own classes. Among these are graphical classes that construct the menu, the toolbar and the application's popup dialogs.
  25
  26 Apart from the general GUI components, graphical representations of the functional classes were needed. MooView (a graphical representation of MooSequence), MooTrackView and MooTrackTitle (MooTrack), and MooNoteElement (MooNote) were therefore added. Supporting these components, some other graphical classes were needed: MooViewCounter, representing a ruler that visualises the time signature of the MIDI file; MooTrackTitle, handling the properties of a track; as well as MooNoteElement and MooNoteProp, supplying a way of editing the properties of a note.
  27
  28 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.
  29 ------------------------------
  30 2.3 Time Schedule
  31 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.
  32
  33 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.
  34 ------------------------------
  35 2.4 Implemention
  36 As we earlier realized, some implementation of the functional classes was required to see what features the graphical representations would need.
  37
  38 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.
  39 [...]
  40
  41 Implementing the strictly graphical classes has at some points been both tricky, and boring. Probably beacuse of the programmers lack of experience of the Java Swing library. Huge amounts of time has been spended with trial and error. The Java Swing library offers rather inflexible layout managers, which sometimes can cause problems. This feature makes it real difficult to get a feeling of how the window actual will look onscreen, while implementing the classes.
  42 In retrospect it maybe would have been better if we chose to work only with the Java AWT library (see section [Problems]).
  43 ------------------------------
  44 2.5 Testing
  45 When it comes to testing, we have not really
  46 In most cases, it doesn't make sense to test the graphical container without its child components. The classes MooGUI, MooView and MooTrackView were all concerned by this.
  47
  48 See section [Implemention and Problems]
  49 ------------------------------
  50 2.6 Major Decisions
  51
  52 2.6.1 Removing some of the functional classes
  53 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.
  54
  55 2.6.2 Adding and removing some of the GUI classes
  56 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:
  57 x MooDialog             A dialog generator class for all the application's dialogs.
  58 x MooInstrumentList     A combo box with the 128 General MIDI instruments.
  59 x MooKeyboard           A keyboard listener emulating a synthesizer.
  60
  61 Two classes, MooStatus and MooNoteProp, were also removed. The status bar was reduced to a JLabel with a single method and was therefore merged inte the main GUI class. The note properties dialog was inserted into the new MooDialog class.
  62 ------------------------------
  63 2.7 Problems
  64 Of all the problems we have come across in our work with Moosique, only one persisted and was until very recently 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 exceeded one second. This obviously made the GUI unresponsive, but also affected 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.
  65
  66 This problem was especially unfortunate since it was the only performance aspect that was mentioned in the requirements specification.
  67
  68 [Ändra font och dra ner textstorlek, citat juh!]
  69 "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."
  70
  71 However, as we recently discovered, the Sun developers were also aware of this issue and, in trying to find a remedy for it, implemented some additional methods for controlling the viewport's visualisation during scrolling. This allowed us to reduce the time lag to a fraction.
  72
  73 Another issue, that could be resolved only through trial-and-error, was the application's interaction with the setSequence method of the Sequencer class. The method employs, as opposed to what is customary in Java, dereferencing of its argument. This means that the MIDI sequence passed to the method is somehow cloned before it is sent to the sequencer, and therefore when the data of the sequence is updated, the changes are not reflected in the sequence currently loaded into the sequencer. In the Programmer's Guide, this method is described as "[tying] together an existing Sequence with the Sequencer, which is somewhat analogous to loading a tape onto a tape recorder". However, the actual implementation of the method (which may be vendor specific) does not work that way, since the "tape recorder" reads the contents of the "tape", but then does not respond to any changes in the "tape" unless the tape is reinserted. This incomprehensible implementation, which is not even hinted at in the API or the Programmer's Guide, didn't cause us a lot of extra work (since we could not understand where the problem was), but postponed a vital step in our implementation to the very last stage of the project.
  74
  75 During our project some time has also been wasted when wrestling with Java Swing components showing up at the wrong position whith the wrong size. No matter how much we studied the API we could not find the answer of this problem. In the end we found out that rebooting our FreeBSD machines was the only cure to this problem. We suspect there is some kind of bug, either in the FreeBSD OS, or the windomaker application we use. After all, we never ran into this problem those rare times we were working on a Windows-platform
  76
  77 The major changes and that not enough work design of the graphical classes resulted in that the different graphical classes couldn't be implemented on their own. Instead changes often had to take place in many different classes when some feature was added. This made the implementation slow, especially in the beginning, since there where many different ideas on how things should be implemented. This got better through time though, when the basic foundation was implemented it got easier to add the rest of the features.
  78 ------------------------------
  79 3. Conclusions
  80 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.
  81
  82 ------------------------------
  83 4. References
  84
  85 LITTERATURE
  86 Sun Microsystems Inc. (2002) Java Sound API Programmer's Guide [http://java.sun.com/j2se/1.4.1/docs/guide/sound/programmer_guide/]
  87 Horstmann, Cay (2003) Computing Concepts with Java Essentials (3rd Edition), New York: John Wiley & Sons Inc.
  88 Jia, Xiao-Ping
  89 McConnell, Steve (1993) Code Complete: A Practical Handbook of Software Construction. Redmond, Wa.: Microsoft Press, ISBN: 1-55615-484-4.
  90
  91 APPLICATIONS
  92 FastTracker II
  93 MidiSoft Recording Session
  94 CakeWalk 5
  95 Cubase SX 1.0