Thanks for the feedback. I though that the standard ALT+F4 and the X button in the top right corner was enough to exit the game. Do you have any specific suggestion for an additional exit method? I'll take note and implement it with the WASD and other additional improvements and fixes once the voting ends to don't break the rules.

Thanks for the kind words! Since it was just a minigame for a jam and I am not experienced on Game Maker I didn't want to make it very complicated. For me the priority was to have something running to submit it on time, more than to have something accurate. I just needed a simple, quick, easy to play casual method with a single track: Yes, I move the pads using room_speed as reference. Everyobject that moves left has this code in their Step:

x -= INPUTS_PER_SEC * DISTANCE_BETWEEN_INPUTS / room_speed;

Where the constant INPUTS_PER_SEC is the amount of keys you'd need to press per second to make it perfect, and DISTANCE_BETWEEN_INPUTS is the screen distance (in native resolution) between the pads. I manually tweaked these values, without reading by code data from the song, to make sure that more or less follows the rythm of the music while at the same time you can see enough upcoming inputs. I also wanted to make sure that difficulty was easy enough for non rythm game players, making sure that almost everyone could achieve a perfect score with maybe just a couple of atempts.

In order to make sure if the inputs have been pressed on time, I use colission of the pad with the white box when a key is pressed. If it's fully inside the box, counts as perfect ("Cool!"), if it's only partly inside the white box counts as "good!", if it only collides with the black bar counts as "Miss!" (too late press), and if it only collides with the blue bar I don't do anything to make sure it's easier for players. I'm not experienced with the collisions in Game Maker and I think it has a couple of collision related bugs, but I thought it was decent enough to submit the game.

I didn't know the BPM of the song, but if it was a fixed one that I was able to sync, it would be easy to modify the formula seen above. A general programming trick (not just GM) for precision calculations in games where you traditionally work with small integer numbers: use real numbers instead of integers and if needed use separated numbers for both things or multiply and divide when needed by a big number (like in the case of the art: In GM you use reals as coordinates, and in pixel art you need to use round() to make sure doesn't look ugly, but if you program somewhere where screen coordinates are int you can use screen pixel coordinates x 1000 (or some other random number stored in some constant) for the game logic, and to divide by this number when drawing. By doing this you'll have an accurated way for the logic precision, and at the same time a small number for when drawing allowing smoother movement.

For a future project I want to investigate a bit the music related code in order to extract stuff like the BPM you mention from the track itself.  Not a rythm game, just to coordinate some background stuff with the music. But for many reasons (like a possible Switch port) I think I'll use Unity for that other project.