# ELEC60013 Embedded Systems - Music Synthesizer Documentation
The following document outlines the design, implementation and real-time dependecies of a music synthesizer for the 2nd coursework of the Embedded Systems module.
**Priority:** Highest, as obtaining the note, volume and octave is required for playing the sound, transmitting over CAN and displaying on the screen. All other tasks depend on the results obtained from scanning the key matrix.
* Decide whether the key was pressed, released or the message originated from the main synthesizer
* Update the array of currently active notes
* Set the current step size, with respect to the currently active note.
**Implementation:** Thread
**Minimum initiation time:** 70ms, assuming an average speed of 14 notes per second for professional pianist, as explained in the following Journal article - https://www.thejournal.ie/worlds-fastest-pianist-1780480-Nov2014/. This thread is an example for which the initiation time is not set internally, which was the case for ```void scanKeysTask(void *pvParameters))```. Instead, this task is a thread, whose initiation time depends on the purpose of the system - in this case, the speed of the pianist.
**Priority:** Medium, due to a lower initiation time, compared to scanning the key matrix. Furthermore, in order to receive CAN messages, they had to be transmitted first - which is handled in ```scanKeyTask```.
**Implementation:** Thread, executing every 100ms.
**Minimum initiation time:** 100ms. While a refresh rate of 10Hz sounds insufficient (compared to modern monitors); the display is largely static. Therefore, 100ms is a perfectly accetable design choice, without any noticeable delays.
**Priority:** Lowest, there is no point in updating the display if the current note, volume or octave have not been update - all of which take placee in the scanning key matrix task.
**Implementation:** Interrupt, executing with a frequency of 44.1kHz. An interrupt is chosen as responding quickly is needed for playing sound. Otherwise, delays between the key press and the sound would exist.
It was desiced to use C++ code(std::atomic), as it is easier to use and implement, while providing the same functionality as a mutex. According to the documentation: *"Each instantiation and full specialization of the std::atomic template defines an atomic type. If one thread writes to an atomic object while another thread reads from it, the behavior is well-defined (see memory model for details on data races). In addition, accesses to atomic objects may establish inter-thread synchronization and order non-atomic memory accesses as specified by std::memory_order.*"(https://en.cppreference.com/w/cpp/atomic/atomic)