O'shea Anaya Githubid: osheaanaya
Shane Masuda Githubid: shanemasuda
Assessment of cs56-music-beatbox
a) Description:
A gui that has the ability to use the MIDI system to create a sequence of sounds from instruments and has the ability to increase or decrease the tempo of the sequence.
b) User Stories:
As a user of cs56-music-beatbox I am able to check any of the checkboxes from 16 instrument rows and create a sequence of 16 sounds. Pressing the Start button plays the sequence sound in a loop however, the sequence sound is not added/removed dynamically so you must press start again to play an updated sequence sound. Pressing the Stop button stops the sequence sound. When pressing the stop button it "stops" the sound near the sound in the sequence at which you pressed the stop button (due to some lag). When you press the Start button again it will start at the sound right after the sound at which you stopped. So pressing Start doesn't always start from the beginning sound in the sequence.(*1) Pressing the Tempo Up button increases the tempo of the sequence sound dynamically while pressing the Tempo Down button decreases it dynamically. After pressing the sendIt button this message is displayed on the terminal:
[java] Sorry dude. Could not send it to the server.
After reading the src code I learned that the sendIt button is supposed to attempt to send a message and the checkbox's state to the server. The message it is attempting to send is anything entered into the "chat" box below it. After pressing the sendIt button the message is deleted.
c) Brief assessment of whether the software runs:
The client class runs and brings up the cs56-music-beatbox gui, however it brings this message to the terminal:
compile:
client:
[java] couldn't connect - you'll have to play alone.
The server class does not run and it brings this message to the terminal:
compile:
server:
We entered in a number of things and nothing happened.
d) Features that could be added:
As a user, I can check the different note boxes and have the sounds be added dynamically instead of stopping and starting again. As a user, I can enter the server name and port into a GUI instead of the command line. As a user, I can see images of the instruments next to their names. As a user, I could have some pre-written background beats as samples to help in building my own. As a user, I could have a checkbox that would switch between dynamically and non-dynamically updating the tempo/sounds.
e) Assessment of the README:
Currently, the README only contains a one sentence description of what the software does. To improve the quality of the README, information about the types of instruments supported, segments of code/classes that aren't working as intended, and a detailed instruction set for using the software should be added.
f) Assesment of the build.xml file :
The current build.xml file is fine. There aren't any targets missing descrptions, and there doesn't seem to be any old JWS stuff that needs to be removed.
g) Assessment of the current “issues”:
Definitely, there are more than 1000 points. Cleaning up the source code is worth 300 points. Fixing the client to properly turn on is worth 100 points. Turning the command line menu into a GUI is worth 200 points. Adding a visual indicator for the beats is worth 300 points. Adding a clear all button for the checkboxes is worth 150 points, and bumped up to 200 points if a reset tempo button is added. This already surpasses 1000 points.
h) Aditional issues:
- Add option to dynamically update the sound Link To Issue
i) Assessment of the actual code:
The purposes of the classes and the methods are very clear, as the follow the beat box example in Head First Java. There are both code and javadoc comments that further clarify the methods as well. There are only two classes, a BeatBoxFinal class and a MusicServer class, and their relations are straightforward. The BeatBoxFinal class sets up the GUI and handles the beat box, while the Music Server class is only called to establish a connection to a server if the user desires to play online. The code is also extremely clear, albeit a few strange spacing issues (for example, in the integer array for the instruments, some of the numbers are seperated by a comma and a space, while some are only seperated by a comma). Every task is handled in a way that makes it clear to the code reader why the actions are being taken. If we had to give a programmer a screenful of text, we would give them the portion of the BeatBoxFinal class that sets up the GUI, and handles ActionEvents, as this is the most important part of the code (it actually makes the checkboxes and buttons do things).
j) Test Coverage:
There is no test coverage, thus there are plenty of opportunities to expand the test coverage. An opportunity to expand test coverage would be to test if the server is able to connect to the CSIL server and if the client is able to connect online to this server. Other tests to implement would be exception testing, as the rest of the tests (for example, checking if an instrument's checkbox actually puts in the correct beat at the correct time) can be done by simply running the program and testing it real time.