x MooTrack The functional representation of a MIDI track. Was to extend Java's Track class.
x MooNote The functional representation of a MIDI note. Was to encompass the two MIDI events that constitute a note: NoteOn and NoteOff.
-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 toolbart, the menu's popup dialogs and the view of the MIDI tracks. All these classes [...].
+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.
-Apart from 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 (a graphical representation of MooSequence), MooTrackView and MooTrackTitle (MooTrack), and MooNoteElement (MooNote). 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; and MooNoteElement, supplying a way of editing the properties of a note.
+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.
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.
------------------------------
In retrospect it maybe would have been better if we chose to work only with the Java AWT library (see section [Problems]).
------------------------------
2.5 Testing
+When it comes to testing, we have not really
+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.
+
See section [Implemention and Problems]
------------------------------
2.6 Major Decisions
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.
+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.
------------------------------
2.7 Problems
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.
projects / moosique.git / blobdiff