Update mathjax and continue Guitar Hero

1 files changed, 37 insertions, 15 deletions

diff --git a/content/projects/guitar-hero/index.md b/content/projects/guitar-hero/index.md
index 857a21f..c69c71b 100644
--- a/content/projects/guitar-hero/index.md
+++ b/content/projects/guitar-hero/index.md
@@ -81,11 +81,6 @@ to play songs. Here is a small excerpt such a file:
   21504 = TS 3
   22080 = TS 4
   ...
-  69888 = TS 4
-  71424 = TS 7 3
-  72096 = TS 4
-  73632 = TS 7 3
-  74304 = TS 4
   75840 = TS 7 3
   76512 = TS 4
   84960 = TS 3
@@ -102,10 +97,6 @@ to play songs. Here is a small excerpt such a file:
   1632 = N 2 256
   1632 = N 4 256
   1920 = N 2 0
-  2016 = N 2 0
-  2208 = N 0 0
-  2304 = N 1 0
-  2304 = N 5 0
   ...
   151008 = N 3 160
   151200 = N 2 0
@@ -128,7 +119,7 @@ goal of the project was to have a functional prototype not a complete replica of
 the game. Let's mainly focus here on the parts of the file specs which were required
 to obtain a minimum viable product.
 
-Most of the `Song` section is fairly explanatory but the **Resolution** field
+Most of the `[Song]` section is fairly explanatory but the **Resolution** field
 merits some explanation. In music, songs have a pulse measured in BPMs (beats
 per minute). For extra precision when it comes to the timing of individual
 notes, *Clone Hero* decided to split each beat into smaller units called ticks.
@@ -149,11 +140,13 @@ R&: \textrm{Tick resolution} \\\\
 \end{align}
 \\]
 
-Something to note is that tick durations need to be calculated very precicely. If
-a tick has a precision of $$\pm1$$ second, the timing is off by an entire second after
-only a thousand ticks. To prevent tht, every calculation made when parsing the chartfile
-was done in nanoseconds. Once every calculation was done, only then were all note values
-converted to milliseconds (which play well with audio files).
+Something to note is that tick durations need to be calculated very precicely.
+If a tick has a precision of $$\pm1$$ second, the timing is off by an entire
+second after only a thousand ticks. To prevent this, every calculation made
+when parsing the chartfile was done in nanoseconds. This way, even after a
+million ticks, an unncertainty of $$\pm1$$ nanoseconds would only result in an
+offset of a single milliseconds. Once every calculation was done, all note
+values converted to milliseconds which play nicer with audio player libraries.
 
 Up to now, this concept seems somewhat elegant. But the format gets much uglier
 when you take into account that many songs accelerate, slow down and/or have
@@ -173,8 +166,37 @@ it's necessary to keep track of two things at each tick change:
 - When did this event occur in the song (nanoseconds)
 - What is the new tick duration value at that time (nanoseconds)
 
+The final piece of the puzzle when parsing is then reading individual notes.
+Each difficulty for a given instrument has it's own section. For the purpose of
+our prototype, only lead guitar (referred to as `Single` in the file) sections
+were parsed as it was the only piece of hardware we had developed. This leaves
+us with the following sections to parse: `[ExpertSingle]`, `[HardSingle]`,
+`[MediumSingle]`, & `[EasySingle]`.
+
+Clone Hero allows some fancy behavior such as tapping notes without also
+strumming. It also allows for strumming without pressing any notes. To keep
+our prototype simple, we decided to limit what we parse to only notes that
+require both strumming and hitting the notes. Such notes show up in the
+following way in a chart file:
+
+```toml
+2208 = N 0 144
+2496 = N 2 0
+```
+
+The first number here denotes the tick at which an event happens, the number
+following the `N` indicates the concerned fret of the note (0-5), and the last
+number indicates the duration of the note (0 means the note doesn't need to be
+held). Next up, we'll look at how the code was structured to contain this info.
+
 # Code Structure
 
+As mentionned earlier, the project had to be written in C++ using the QT
+library for visuals. We therefore need some sort of way to link visual objects
+to notes parsed in the aforementionned `.chart` file. From least to most
+specific, this is a simplified version of how we decided to store the
+information:
+
 {{<mermaid>}}
 classDiagram
   direction RL