This is more for me to keep a track of shit, but here's the lowdown:
Using ButtplugUtils.vibrate() on beatHit leads to inconsistent vibration strength, plus the frontend relies on funkin to send a stop command meaning lag spikes can skip a stop command.
Payloads aren't much better. While the vibration is consistent and we're not relying on funkin for stop commands, the vibrations start to go out of sync with the music despite the fact that the timings are plucked directly from the conductor's crochet variable.
This also goes for sending a non-looped payload every beatHit().
The first option is definitely a no-go.
The second and third are harder to figure out. Current thinking is that the frontend's taking too long to send the commands, or it's somehow struggling. Latency shouldn't be a problem as I test on a wired xbox controller. More research (and probably fucking around with the frontend) is required to really pin this down.
Fixed it, turns out I wasn't giving the frontend enough breathing room with the 3rd option by having the 0 speed command in the payload be half of a beat. Fix will be pushed in an upcoming commit.
This is more for me to keep a track of shit, but here's the lowdown:
The first option is definitely a no-go.
The second and third are harder to figure out. Current thinking is that the frontend's taking too long to send the commands, or it's somehow struggling. Latency shouldn't be a problem as I test on a wired xbox controller. More research (and probably fucking around with the frontend) is required to really pin this down.