I think there are two misconceptions there:
-
How input detection works frame-by-frame. You did two cases that are actually exactly the same as each other. If you hold B the entire time while advancing frames, that’s actually the same thing as holding B, advancing 1 frame, releasing, holding B again, advancing 1 frame, releasing, etc. In both of these cases, B is always down when the frame is advanced, so they both produce the same result (on purpose) because the game is seeing that as one long hold. It sounds like you expected these two things to have different results.
-
The connection between startup/active/recovery and input windows for cancels. There’s no connection there. If startup/active/recovery lit up, that would not help you at all understand when the cancel windows are.
The actual solution to what you’re trying to do (to get B, B to come out as soon as possible) is an input sequence something like this:
- Advance a frame while B is held
- Advance a frame with nothing held
- Advance a frame while B is held
- Advance a frame with nothing held
- Advance a frame while B is held
- Advance a frame with nothing held
- etc…
This means the game does NOT see you as holding down B the entire time. So it will now actually be possible to get the second move in the B,B sequence. Furthermore, you will definitely get it as soon as you possibly can. That sequence will have you either pressing B on the first frame the cancel is possible, or 1f earlier, which will still give you the cancel at the first possible moment.
There’s a ton more leniency than that, actually. You could input B 8 frames before the earliest moment, and even if you don’t press B again, you STILL will get the cancel as early as possible. I was just giving one example that works with thing where you alternate B, nothing, B. You could be sloppy and do like B, nothing, nothing, nothing, B, nothing, nothing, nothing, B, etc and that works too.