Differences

This shows you the differences between two versions of the page.

--- proj [2022/01/11 17:28] – bil
+++ proj [2022/03/07 22:19] (current) – bil
@@ Line 3: / Line 3: @@
 ====== EECS 2311 Project ======
-<html><!--
-====== New requirements added on March 3! ======
-  - The system must allow the user to improve the MusicXML output **by editing the input text tab**. For example, if the output for measure 42 is not what the user was hoping for when they load your output onto a viewer, your system must present this measure (or a range of measures) so that the user can edit accordingly. This includes metadata such as setting a different time signature for some of the measures.
+====== New requirements added on March 7! ======
-  - The system must allow the user to save any edits made to the input text tab by the user, including any metadata edits, e.g. song title, time signature etc.
-  - The system must support [[https://www.musicxml.com/tutorial/the-midi-compatible-part/repeats/|repeated measures]]. The drum example below contains many instances of repeats. See an example in the Useful Resources section below.
+  - The system must allow the user to customize the visual output to improve it aesthetically and functionally. This definitely includes adjusting the spacing between notes in order to have both the left and right ends of the output align (similar to text justification in a word processor). It can also include customizing fonts, the spacing between the lines of the staff, the size of the notes etc.
-  - The system must also support [[https://usermanuals.musicxml.com/MusicXML/Content/EL-MusicXML-grace.htm|grace notes]]. For guitar, any sequence of hammer-ons, pull-offs, or slides that is preceded by the character "g" should be treated as grace notes. For drums, flams (designated by the character "f" in the tab) must be implemented as grace notes. See an example in the Useful Resources section below.
+  - Repeats must be supported as well. Try {{:repeat.txt|this example}} input on MuseScore to see the expected output.
-  - The system must deal with errors in the input in a user-friendly way. Minor errors should be treated as warnings but should not stop the conversion process. Major errors in particular measures must be presented to the user to fix them.
+  - The previewer should allow the user to see what measure number they are looking at, as well as support a Go To Measure function as in the text input.
-  - The system must of course support all three instruments and as many as possible of the features shown in the two examples below.
+  - The play function must allow the user to change the tempo of the music, i.e. how fast or slow it is played back. This must be expressed in beats per minute (bpm). 60 bpm means that there are 60 quarter notes in a minute, i.e. each quarter note lasts one second.
+  - There must be a connection between the play function and the visual output as follows: The user must be able to select a measure (or a note) and start playback from that point. Also, when the music is playing, the visual output must highlight the note that is currently being played (similar to MuseScore).
+<html><!--
   To be posted.
@@ Line 21: / Line 22: @@
 <hr/>
 --></html>
+====== Original project description ======
 Anyone interested in learning how to play a particular piece of music can usually find help on doing that on the internet in a variety forms, such as videos or tutorials. A common way to convey the way to play a given song for instruments such guitar, bass, or drums is through the use of tablature or tab. These are often created in text as it is the easiest format to do that in.