-Foreword (optional)\r
-\r
-OBS! [...] = Hjälp till om ni kan och lägg in text\r
-\r
-1. Introduction\r
-\r
-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 visualization 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.\r
+Foreword (optional)
+
+OBS! [...] = Hjälp till om ni kan och lägg in text
+
+1. Introduction
+
+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 visualization 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.
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.
-\r
-2. Analysis\r
------------------------------\r
-2.1 The Java MIDI Package\r
-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.\r
------------------------------\r
-2.2 Design Document \r
-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.\r
-\r
-In a hierarchy below the Moosique class, we placed three classes that represented the different parts of a MIDI file: \r
+
+2. Analysis
+-----------------------------
+2.1 The Java MIDI Package
+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.
+-----------------------------
+2.2 Design Document
+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.
+
+In a hierarchy below the Moosique class, we placed three classes that represented the different parts of a MIDI file:
x MooSequence The functional representation of a MIDI sequence. Was to extend Java's Sequence class.
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 toolbar and the view of the MIDI tracks. All these classes [...]. \r
-\r
-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 visualizes 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.\r
-\r
-We design the structure of the application very quickly, perhaps to 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]).\r
-------------------------------\r
-2.3 Time Schedule\r
-Before we started implement the classes, 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
-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
-2.5 Testing\r
-------------------------------\r
-2.6 Major Decisions\r
+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 view of the MIDI tracks. All these classes [...].
+
+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 visualizes 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.
+
+We design the structure of the application very quickly, perhaps to 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]).
+------------------------------
+2.3 Time Schedule
+Before we started implement the classes, 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.
+------------------------------
+2.4 Implemention
+As we earlier realised we needed to implement the functional classes first. This to see what references the graphical representation might call. [...]
+ Strictly graphical classes [...]
+------------------------------
+2.5 Testing
+------------------------------
+2.6 Major Decisions
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
+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.
+
+[...]
+------------------------------
+2.7 Problems
+[...]
+------------------------------
+3. Conclusions
+
-[...]\r
-------------------------------\r
-2.7 Problems\r
-[...]\r
-------------------------------\r
-3. Conclusions\r
-\r
-\r
-4. References\r
+4. References
LITTERATURE
Sun Microsystems Inc. (2002) Java Sound API Programmer's Guide [http://java.sun.com/j2se/1.4.1/docs/guide/sound/programmer_guide/]
-Horstmann, Cay (2003) Computing Concepts with Java Essentials (3rd Edition), New York: John Wiley & Sons Inc.
-Jia, Xiao-Ping\r
-Code Complete\r
+Horstmann, Cay (2003) Computing Concepts with Java Essentials (3rd Edition), New York: John Wiley & Sons Inc. ISBN: 0-471-24371-x
+Jia, Xiao-Ping (2000) Object-Oriented Software Development Using Java, Addison and Wesley Longman, Inc, ISBN: 0-201-35084-X
+MCConell, Steve (1993) Code Complete, Redmond: Microsoft Press, ISBN: 1-55615-484-4
APPLICATIONS
-FastTracker II\r
-MidiSoft Recording Session\r
-CakeWalk 5\r
+FastTracker II
+MidiSoft Recording Session
+CakeWalk 5
Cubase SX 1.0
projects / moosique.git / commitdiff