simon-wh
commented
2 years ago Hmmmm, to me it sounds like this is due to the SDK's general initialisation being a sync function and the initial finding of devices is sync, but the analog data only starts being read in a new thread so its async. So there's no guarantee that the SDK will be ready to report the device's analog immediately after initialisation.
I'm surprised that such a long delay is needed to get it to report the values, I'd imagine that the max time needed would only need to be a few ms to account for the time in-between the reading thread starting and it receiving the next analog report coming in from the keyboard
If your application is needing the values of keys over the lifetime of the app I'd just ensure that you init the SDK early on so it's already got some analog data coming in by the time you need it
Sorry for the late response, I lost track of this issue
When an analog read is performed (either for a specific key or for all keys) for a key that was already pressed before initialization, it sometimes returns 0.0 instead of the correct value (and does not appear in the list returned when reading all keys). Doing consecutive reads, the second one may still give the incorrect value. Adding a (100ms) delay between initialization and reading seemed to fix the issue (maybe a race condition?).
Some environmental details in case they are of interest: SDK Version: 0.6.0 Language: C++ (compiled with g++ -std=c++14 -o2) System: Ubuntu 20.04 Keyboard: Wooting Two HE