Skip to content

Latest commit

 

History

History
38 lines (28 loc) · 5.72 KB

F17_lab03.md

File metadata and controls

38 lines (28 loc) · 5.72 KB
Raw

By: Erick Suarez, Yash Rane

A) A brief description of the project. Here, I’m looking for a short description: probably 1 sentence, 2-3 at most.

A graphic user interface that allows the user to mix together instrument sounds as desired just as the name "beatbox" suggests.

B) A set of user stories (as a X I can Y so that Z) that describe what the current software in its current state can do.

  1. As a user I can select check boxes in order to include as many instruments as I desire from the list as many times as I want in the span of the song so that I can hear them when I start the song in any combination I want.
  2. As a user I can press the start button to start hearing the mix, or to reset to start at the beginning of the mix.
  3. As a user I can press the stop button to stop the mix from looping.
  4. As a user I can press the Tempo Up and/or Tempo Down to control the tempo of the song as I desire.
  5. As a user I can press the sendit button to send my mix to the server.

C) A brief assessment of whether the software runs or not. If it runs, briefly describe what it does.

The software runs displaying a gui of a simple beatbox. It allows the user to create a mix using 16 instruments and 16 time intervals at the user's disposal. To begin the mix the user can press start which loops the mix once it finishes, if the user presses start button again it resets. If the user presses the stop button when no mix is playing, nothing happens, if the mix is playing, then the stop button, stops the mix. A tool the user has is the ability to increase or decrease the current tempo of the song. The user can also press the sendit button to send the mix to the server.

D) A set of user stories (at least 2, but you are encouraged to write up to 4 or more if you can, as many as you think is reasonable) about features that COULD be added to the software to make it more useful, fun, better, etc.

  1. As a user I should be able to add sounds dynamically once the start button is clicked
  2. As a user if I click start without having clicked any check boxes, error message should appears, so that I know what is allowed
  3. As a user I should be able to have different categories of sounds such as instruments, effects, melodies, voices, etc... to create unique sounds.
  4. As a user I should be able to save my sound file to have for whatever purpose i desire.

E) An assessment of the current quality of the README.md. What information could be added to make it easier for the next generation of folks maintaining this code to use the software, and/or maintain the software?

Terrible, its only a sentence description of what it does. Information that could be added includes but not limited to: How to set up the environment, a high level view of how the project works as a whole, details of how parts of the code work and what they're for.

F) An assessment of the current state of the build.xml file. Are there targets that need descriptions? Is there old legacy JWS stuff that needs to be removed? (More on this below).

The current state of the build.xml is fine. There's enough information so with a bit of digging you can figure out how to use, but can be improved. It also does not look like there is old legacy JWS stuff that needs to be removed.

G) An assessment of the current “issues”. Are there enough issues that you could earn 1000 points by working on this project? Are the issues clear in terms of what the expectations are?

There are plenty of issues on this project. The 16 open issues encompass a wide range of problems from improving the readme to adding a visual indicator of beats, so we could earn 1000 points working on this project. Some of the issues, however, are vague. For example, one of the issues is "Copy Button." Unfortunately, it doesn't say what button needs to be copied.

H) A list of additional issues that you may have added, if any. For each, a link to the issue is good enough.

Issue #23

I) Most important: an assessment of the actual code. Write a bit about how the code is organized. Are the purposes of the classes, and their methods clear? Is it obvious how the classes relate to one another? Is the code easy to read and understand? If you had to give someone else that was going to work on the code just “one screenful of text” to help that programmer get up to speed quickly, what information would you convey?

The code contains two source files: BeatBoxFinal and MusicServer. BeatBoxFinal seems straightforward; It builds a track based off of several midi instruments and plays it. MusicServer, on the other hand, is harder to understand. It appears to connect to something through the internet, and then write two objects to a clientOutputStream. However, there is no mention of what these objects are or what the server is used for. The only other information I could give to bring someone up to speed is that it seems that the entire server code needs to be scrapped, based on an issue that says to remove the server/chat. Also, as this project is still in its early stages, It would be up to the programmer to decide what direction the project goes in.

J) Related to code quality, but factored out into a separate issue because it is so important: how is the test coverage? Are there JUnit tests at all? If so, how much of the project is covered by testing? Are there opportunities to expand test coverage, and if so, how would you go about it?

There don't appear to be any tests written for this project, Junit or otherwise. There could be an opportunity to write tests in the code that loads in and plays tracks. They would probably be tests to see if a track has been loaded and if an event has been created properly.