Hi! This is actually not me asking for help, but more just me providing it. I've been struggling to find a good and accurate timing system that 1: works FPS-independent, of course, since we don't want inconsistent rhythm, 2: feels accurate to what you actually input, and 3: doesn't have to deal with the weird rounding stuff the timer block can sometimes do.

DISCLAIMER: This does actually have a thing where rounding with the timer could cause an issue, but it's kind of rare and mostly depends on lag.

How the rhythm game system typically works
If you already have complex rhythm game knowledge and stuff you can probably skip this whole thing, this is just to explain stuff that isn't really clear when making a rhythm game.

Inputs are almost always based on a hit window. The hit window is a space of time where a note can be pressed. This is not actually immediately obvious, as in most rhythm games, especially VSRGs or Vertical Scrolling Rhythm Games, objects seem to be deemed accurate or not based on position. But this makes a big problem, which is that changing your scroll speed also changes the precision. If you're the kind of person who likes reading slower gameplay to see more notes farther ahead, then you'd also be getting an unfair advantage since you get more time to make an input. And if you're like me who likes faster scrolling so I can differentiate patterns and spacing easier, then that gives you a really big disadvantage.

But this is what it looks like when you use a hit window.

Since both notes are calculated based on time, the hit window seems to extend or shrink depending on scroll speed. This is the main thing we're going to be focusing on.

To make things simple, let's also assume the scroll speed is based on time as well, with something like a glide block to move the note.
Here's a super basic way to make a time-based hit window

set [start timer v] to (timer)
repeat until <((start timer) - (timer)) > ((Scroll Speed) + ((Hit Window) / (2)) )>
if <((start timer) - (timer)) > ((Scroll Speed) - ((Hit Window) / (2)) )> then
if <((start timer) - (timer)) < ((Scroll Speed) + ((Hit Window) / (2)) )> then
this block indicates that it knows if it's in the hit window
end
end
end

With that out of the way, let's look into the actual timing system

THE THING THAT'S ACTUALLY IMPORTANT

The problem with Scratch is that it's only 30 frames per second, which makes timing really weird especially since the timer can be a bit more or a bit less than what you expect at any given time. This is what my idea does, it calculates accuracy based on what specific frame it's in.

First, we're gonna have to make the note estimate how long they will be in the hit window, in FRAMES, not seconds. I don't want to recreate the whole thing but this is what I did to estimate how many frames it takes. hwTimer is basically just the start timer from earlier.



An easier, but way worse solution, is to measure how many frames it takes only once, and apply that for every other note. But of course this is inaccurate because lag exists, duh. But estimating it for each note just makes everything way more accurate.

This is better because even if the note's timer is a little late or a little early, its accuracy will still feel the same as the other notes. Usually. This also makes calculating hit latency extremely easy, since you just divide the amount of frames the note has been in the hit window by the estimated amount of frames it takes to complete it.

Then of course you can assign that latency to different judgements and accuracy and whatnot.

I've gained so much rhythm game engine knowledge at this point that I should probably make a full on Scratch rhythm game tutorial since literally nobody has done that properly yet lol

as someone who has TRIED to make a rhythm game.. (for note my attempts are on my profile)

i genuinely forgot hit windows existed because im so used to just relying on note position and patterns

Hello! It's great that you want to help out other Scratchers. However, I think we have enough guides in the forums at the moment. Please feel free to welcome new Scratchers on the group welcoming topic or on individual topics created by New Scratchers.

Other places that can always use more helpful Scratchers like you, are the "Help With Scripts“ and ”Questions About Scratch" areas - please use them as designed, by responding to topics created by folks with problems to solve

Finally, a really good place for Scratch guides is the Scratch Wiki - check it out and see if it's something you might like to work on. They have a number of guides - and great organization.