I moved the start of the storyboard to match the slider's start again, that was an oversight on my part

I've had the same concerns when designing it but kept it like that at first because I assumed the static wouldn't be as bothersome at the time. I've now nerfed the static on the final slider a fair bit (mainly squished the boxes into much thinner lines) so this should hopefully alleviate the problem. Lemme know if you think it needs a bigger nerf

Got rid of both the unnecessary Fade and the Rotate commands. The sprites should now have only one F and R command instead of two. The reason for removing the first R command is because the second one already applies the same rotation the first one does at the start.

I forgot to change the start time in some cases, should be completely fixed now ~

Good eye! Fixed the numbers so the right amount of sprites should be appearing now!
Sadly this resulted in a slightly bigger .osb size but the performance impact should still be much lower compared to the previous effect.

Thank you for the detailed and very insightful mod!

The obsolete fade was a mistake on my side. It was supposed to be added to the loop as a delay but I forgot the adding part. More specifically using your case, this was supposed to be
F,0,11070,18,400,,0
in order to extend the loop.
Coloring end times were aligned to the sprites last fadeout time now!

While I understand your idea and it is a valid point, it doesn't work in this case mainly because of their easings. Using a shorter transition time with a non-linear easing will cause the rings to misalign even if they match in scale values. Hence why using the same scale duration for both is the only solution.
Your idea would work if the scale commands didn't use any easings.

Very good point! Changed all looped sprites from this specific effect into more shorter duration sprites. Given that their active time is now shorter than a beat, rather than the full chorus, this should be a great improvement to performance.
Filesize increase is negligible.

Changed the math behind calculating their loop count a bit so they should end before or around the time their movement command ends now.