Closed SuhEugene closed 8 months ago
I might not get in front of a real keyboard until tomorrow, but the big thing I think wants changing is that the vibrate command handler should probably return the new vibration command after setting it for the loop. That way you don't have to do any of the last value checking in the loop and the loop can sleep longer and use fewer cycles.
I might not get in front of a real keyboard until tomorrow, but the big thing I think wants changing is that the vibrate command handler should probably return the new vibration command after setting it for the loop. That way you don't have to do any of the last value checking in the loop and the loop can sleep longer and use fewer cycles.
I got to a keyboard!
I also happened to receive a new metaXsire device with a very similar command pattern, that's got a lot of the same repeating pattern: https://github.com/buttplugio/buttplug/pull/603/commits/e6ef63f54af75da47c09d08d1d7ffa780e046aeb#diff-4fe286dab6c3ad0e0859445fcfdd7c65df07182b80998fe850f936451b0cf2f0
@qdot I think my comments are all addressed within reason. I think this can probably land.
@SuhEugene FYI my hardware has arrived, so I'm able to test now, and I don't think this is behaving as expected: it feels like there's weird lag (like it's not always stopping) and worse, when I restart my test app after controlling the hardware but not restarting the device, it ignores commands outright.
Did you see anything like this in your testing?
@qdot I squashed this PR + the final tweaks to work properly with my model into https://github.com/buttplugio/buttplug/pull/603/commits/4ef42477e07f78629dd2358e3e2b4d671d4b0da2
I implemented it as a new protocol because I'm afraid of breaking something that already exists.
This is my first time using Rust so I'm sorry for making your eyes bleed.
Protocol documentation: