From the doc: the Metronome system

The Metronome system was probably the most confusing idea to my fellow developers and the least noticed part for our players. Below is a brief description of the design, and an excerpt from the post-mortem on the technical difficulties we had with integrating the system with the music (and therefore making it actually noticeable).

Micro Missions uses a light version of a metronome system. The metronome system was developed by GL33k, a collective of independent game audio developers, and first used in the game Mushroom Men. Bobby Arlauskas made a poster presentation about the idea at GDC 2012 (http://gl33k.com).

The idea of a metronome system is to provide beat-based timing cues for the whole game to use in place of traditional time measurements, like seconds and milliseconds. This process makes the timing of events and transitions synchronized with the music and simultaneously dependent on the music speed. If all events synchronize to the same beat, the player can predict the timing of events better. There is also more opportunity for serendipitous synchronization between various happenings on the stage at any given moment. This system is meant to be quite subtle and is not necessarily intended to be consciously noticed by the player.

In Micro Missions, the metronome is used primarily to measure how long mini-games, cutscene frames, and instructional overlays should last. Micro Missions has four different musical themes, each with its own speed. So, changing the theme can affect gameplay by changing the speed of the game.

From the post-mortem

One of the biggest issues arose when we were trying to tie the Metronome system to the Sound Engine. The Sound Engine was meant to trigger the next loop of the music exactly in time with the Metronome beat, so that the music and the gameplay match up. However, this design caused a small but very noticeable piece of the music to be skipped, as if the music player ran out of time and could not finish playing the previous loop iteration before the next one started.

The cause turned out to be caused by Flash taking a non-negligible amount of time to actually start playing the music. Moreover, this amount of time was very inconsistent, which made it impossible to compensate for.

We ended up scrapping the synchronization system and simply starting a new playthrough of the loop when the old one finished. This did not get rid of sound artifacts completely, since the sound froze a little while Flash thought about how to start playing it again.