Differences

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

--- proj [2021/03/03 19:00] – bil
+++ proj [2022/05/05 15:26] (current) – bil
@@ Line 3: / Line 3: @@
 ====== EECS 2311 Project ======
-====== New requirements added on March 3! ======
-  - The system must allow the user to finetune the MusicXML output by editing the input. 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.
-  - The system must allow the user to save any edits made to the input.
-  - 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.
-  - The system must also support [[https://usermanuals.musicxml.com/MusicXML/Content/EL-MusicXML-grace.htm|grace notes]]. Any sequence of hammer-ons or pull-offs that is preceded by the character "g" should be treated as grace notes.
-  - 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 system must of course support all three instruments and as many as possible of the features shown in the two examples below.
 <html><!--
@@ Line 47: / Line 39: @@
   * You can preview any MusicXML file by dragging and dropping it onto [[https://opensheetmusicdisplay.github.io/demo/|this page]].
-<html><!--
+  * An example of a {{:examplerepeat.txt|guitar text tab with a repeated section}}, and the {{:examplerepeat.musicxml.txt|corresponding MusicXML}} file. Note the number 4 on top of the last bar that designates the section is to be repeated 4 times. Your system must support repeats as shown in this example, as well as in the drum tab example posted since the beginning of the term (War Pigs by Black Sabbath).
-Venn diagrams are a great way to present
+  * An example of a {{:graceexample.txt|guitar text tab with a grace note}}, and the {{:graceexample.musicxml.txt|corresponding MusicXML file}}. Unfortunately, the online viewer posted above does not show grace notes in tablature, so you should use MuseScore to test grace note functionality.
-relationships between sets of objects, such as
-set intersection or set difference. They can be drawn in many different ways
-We will develop a desktop app that can draw
-**customizable Venn diagrams**.
-Precise requirements will be derived during the term.
-====== New requirements added on February 26! ======
-  - Your system must allow the users to select multiple objects at once in order to customize them, e.g. select all objects in the intersection, and increase their font size
-  - Your system must also implement an Undo / Redo mechanism
-====== Stakeholder requirements added on March 3! ======
-  - Each element in the Venn diagram may have a longer description that is by default hidden, but the user must be able to display it
-  - The app must support a mode where the user is asked to arrange a set of tags on the Venn diagram. Once finished, the user can compare their arrangement to a previously hidden correct answer
-TalkBox is a device that helps anybody, who is unable to talk, communicate.
-Each TalkBox has a number of buttons that the user can press to play pre-recorded audio files.
-Some of the buttons on the TalkBox may be used to load different sets of audio files.
-{{:talkbox.jpeg|TalkBox}}
-We will develop two pieces of software to help family members configure a TalkBox device with audio appropriate for their situation.
-**1. TalkBox Simulator**
-A piece of software that simulates the behaviour of any TalkBox device.
-Has a user interface similar to that of the device.
-The number of buttons and their functionality is configurable.
-Is fully tested to behave as the hardware device.
-**2. TalkBox Configuration app**
-A user-friendly GUI-based app that allows for the configuration of a TalkBox device with appropriate audio.
-It will provide facilities to record audio, or select already pre-recorded audio files.
-It will allow the user to associate audio files with buttons in an intuitive way.
-It will store the configuration in a USB flash drive to be used with an actual TalkBox, or will launch the Talkbox Simulator to test.
-The TalkBox Configuration app and the TalkBox simulator will communicate through the use of a TalkBoxConfiguration object that will be serialized
-**Important Requirement**: Your code must serialize and deserialize an object that implements the [[http://www.eecs.yorku.ca/~bil/2311/TalkBoxConfiguration.java|TalkBoxConfiguration]] interface.
-The TalkBox Configuration app must create a directory called TalkBoxData that contains the serialized object (extension must be .tbc) and the audio files. It can then launch the TalkBox Simulator and provide the path to the TalkBoxData directory as a runtime argument.
-**New requirements added on March 6**
-**New Simulator requirement**: If the user presses a button while an audio is playing, that audio stops before the audio corresponding to the button starts
-You may have to look into naming, searching for, and stopping threads
-**Second new requirement**: Your system must log all actions the user takes in both apps
-What buttons they press, what menu options they select etc.
-The Configuration app must have a way to visualize the Simulator logs
-This will allow the caretaker to optimize the configuration
-You must also create **a third app**, called TBCLog, that visualizes the Configuration app logs
-The purpose of this app is for the research team to determine how users use the Configuration app
+====== 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.
+  - 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 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.
+  - 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 system must of course support all three instruments and as many as possible of the features shown in the two examples below.
+<html><!--
   To be posted.