2 files changed, 54 insertions, 22 deletions
diff --git a/content/projects/guitar-hero/index.md b/content/projects/guitar-hero/index.md
index b364350..857a21f 100644
--- a/content/projects/guitar-hero/index.md
+++ b/content/projects/guitar-hero/index.md
@@ -13,7 +13,11 @@ Hero* using C++ and QT.
 The goal of this class was to teach Computer Science students about GUI design
 as well as teach electrical engineers about PCB design. Both type of students
 would also get to learn about software and hardware integration. Each team
-was composed of 6 people of both engineering discipline.
+was composed of 6 people of both engineering discipline. If you're wondering how
+this project turned out, here's a little youtube playlist showcasing hardware
+software and the integration between both that we achieved:
+
+{{< youtubepl PLGcbRdKslprBkKg2NyGtS4AGuB2Ng_22e >}}
 
 # Requirements
 
@@ -42,9 +46,7 @@ With those imposed constraints, we set ourselves a few targets of ourselves.
 - Satisfying fret buttons
 - Good input and visual latency
 
-# PCB and Guitar Design
-
-# File Parsing & Structure
+# File Parsing
 
 *Clone Hero* is a popular game inspired by *Guitar Hero* where
 players can download and play community developed songs. It uses
@@ -121,18 +123,57 @@ to play songs. Here is a small excerpt such a file:
 }
 ```
 
+This file contains a lot of information which didn't get implemented as the main
+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
 merits some explanation. In music, songs have a pulse measured in BPMs (beats
-per minute). For extra precision for note timing, *Clone Hero* decided to split
-each note into smaller units called ticks determined by the resolution. Using
+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.
+The duration of a tick is determined by the resolution two things, the
+resolution parameter stored in the song section, and the BPM of the song. Using
 easy numbers, if a 60 BPM song (1 beat lasts 1 second) had a resolution of
 1000, each tick would have a duration of 1 millisecond.
 
-Up to now, this concept seems elegant. But the format gets much uglier when you
-take into account that many songs accelerate, slow down and/or have small non
-musical intermissions. So how can ticks remain reliable if the tempo of a song
-isn't always the same? The file spec requires a `[SyncTrack]` section
+A more formal way of expressing this is as follows:
+
+\\[
+\begin{align}
+T &= \frac{B^{-1}}{R}        \\\\
+\mathrm{where}               \\\\
+T&: \textrm{Tick resolution} \\\\
+B&: \textrm{Current BPM}     \\\\
+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).
+
+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
+small non musical intermissions. So how can ticks remain reliable if the tempo
+of a song isn't always the same? The file spec requires a list of `B`
+parameters in the `[SyncTrack]` section. Here is one from the section above
+
+```toml
+  1152 = B 162000
+```
+
+What this states is that at the 1152th tick, the song now becomes 162.000 BPM.
+There is no period in the format. It is implicit that the three last digits of
+the BPM value are decimal points. From a practical standpoint, this means that
+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)
+
+# Code Structure
 
 {{<mermaid>}}
 classDiagram
@@ -171,20 +212,11 @@ classDiagram
   Chord o-- Song
 {{</mermaid>}}
 
-
-
-
 # GUI Design
 
-# Results
-
-Here's a small playlist showcasing what we managed to achieve after a semesters
-worth of work, both hardware and software wise:
-
-{{< youtubepl PLGcbRdKslprBkKg2NyGtS4AGuB2Ng_22e >}}
-
-
+# PCB and Guitar Design
 
+# Communication layer
 
 <!-- Integration   https://youtu.be/FKOd6nEcEC8 -->
 <!-- Song          https://youtu.be/G2GX4o7dhNY -->
diff --git a/content/projects/uebersicht-todoist/index.md b/content/projects/uebersicht-todoist/index.md
index dbfd2b0..4161e85 100644
--- a/content/projects/uebersicht-todoist/index.md
+++ b/content/projects/uebersicht-todoist/index.md
@@ -1,7 +1,7 @@
 ---
 title: "Todoist Task Viewer"
 date: 2023-10-23T23:20:05-04:00
-draft: false
+draft: true
 ---
 
 Back in 2018, I daily drove a mac and I really wanted my daily tasks