Guide
Why the notes always land on the bounces
A common way to make a physics music video is to play a sound whenever the game engine reports a collision. It works for a live demo but drifts in a recording, because the sound is triggered when the frame is processed, not at the moment of impact, and frames are never perfectly on time. Melody Bounce does it the other way round.
Physics first, sound second
Each scene runs its whole simulation before anything is drawn. The physics uses a fixed time step, between 360 and 960 steps per second depending on the scene, so fast balls can't skip through walls between steps. Each collision is written to a list with its time to a tenth of a millisecond.
The soundtrack is built from that list. Each collision takes the next note of the melody, and its sample starts at exactly time × 48,000, the audio frame of the impact. Hits that land within a few dozen milliseconds of each other share a note, so dense moments stay musical rather than turning into noise.
Drawing from the same data
The picture is drawn from the same simulation, frame by frame: frame 437 of a 60 fps video shows the state at 7.283 seconds, and the note for a hit at 7.280 seconds starts 160 audio samples before that point. Nothing is played back live, so there is nothing to drift.
Why the same variation gives the same video
The randomness in each scene (starting positions, small nudges after a bounce) comes from a seeded random number generator. The variation number is the seed. Same seed, same events, same notes, same video, on any machine. That is also how the engine is tested: the TypeScript port is checked against the original Python scripts, event by event.
In the browser
The maker runs the simulation in the page and builds the soundtrack in a background thread. When you export, your browser renders each frame, encodes it with the WebCodecs API and muxes it with the audio into an MP4. The code is open source if you want to look under the hood or render from the command line.