Conductor fixed

[Lasercar]

Does this PR close any issues? If so, link them below.

Fixes #4332, fixes #4304, fixes #4176

Briefly describe the issue(s) fixed.

Fix for the conductor - fixes the stuttering, the conductor updating when not focused, the song not ending properly, and the playspeed not being used issue.

There's a weird thing where GF's animation jumps when you spam pause and unpause with this but I don't really see a problem in that.

There's an interesting issue where GF's neck snaps at high framerates when you spam pause and unpause when the music's time is passed into the conductor instead (which only happens in this PR and the playspeed fix, when the pitch is different so that it's actually used). Basically, GF's dance breaks somehow and it snaps between the left and right dances, as if the onStepHit is being called too many times. Though weirdly, it doesn't affect characters (or just boppers in general) that don’t have dance left and right animations.

Include any relevant screenshots or videos.

[Hundrec]

There's a weird thing where GF's animation jumps when you spam pause and unpause with this but I don't really see a problem in that.

This is a problem.

what.did.they.do.to.you.mp4

[Lasercar]

There's a weird thing where GF's animation jumps when you spam pause and unpause with this but I don't really see a problem in that.

This is a problem.
what.did.they.do.to.you.mp4

I'll keep the other two PRs open, in that case.

Hmm, I guess it doesn't hurt to use the conductor's position for now, if the pitch is 1, until a fix is found or whatever.

[Lasercar]

Issue also happens on 0.5.3 with the changes:

2025-03-17.00-03-23.mp4

So, it isn't the result of any of the changes currently on develop.

[Lasercar]

Hmm, now that fix for the song ending bug has been merged, will these changes still be needed or will #4182 suffice?

[KoloInDaCrib]

The recent changes actually made the game unplayable since now it checks for whether or not the game is out of focus for it to update the conductor

In my opinion the if-cases should be something like this

In this if-case (admittedly a bit hectic) it checks:

• If the game is focused on while autoPause is activated

OR

• autoPause is deactivated (the game updates all the time, regardless if the game window is focused on or not)

However, considering flixel already internally handles the update() function and when it should be called, this PR is essentially just your other PR that implements playbackSpeed, which makes this PR somewhat pointless. (unless you can somehow fix the conductor skipping forward that doesn't cause gf to skip to her next animation and therefore snap her neck - I didn't have that much success by using the justUnpaused variable but you may have something else in mind for this)

One last thing since I may not have a chance to mention it again - I don't think this pr or any of its previous versions "fixed" constant resyncing, as I think it was fixed by this commit which was merged to develop a while ago and that the other person who attempted to fix the issue themselves probably hadn't tested the develop branch to see if it was already fixed

[Hundrec]

This PR needs a rename, but I'm not really sure what to call it!
Does anyone have any ideas?

[Lasercar]

This PR needs a rename, but I'm not really sure what to call it! Does anyone have any ideas?

#5107