|
|
|
|
|
|
by errantspark
704 days ago
|
|
|
I tried to use buttplug years ago but I found it to be difficult to work with and introduce too much latency into play. My partner and I have replaced it with 37 lines of javascript that give us more realtime control of our toys (albeit only Lovense, by just spamming .writeValueWithoutResponse()). I'm curious what your background is that you approached the problem in the way that you did? I appreciate that you're covering all the edge cases for a lot of different toys, but it also really feels like you use 1000 lines of code where 10 will do. |
|
|
Ok. Let's break this down.
The library currently handles support for 523 different devices from at least 40-50 manufacturers. (https://iostindex.com/?filter0Availability=Available,DIY&fil...).
These devices can connect over bluetooth le, usb (both raw and HID), serial, or one of several network protocols. We support windows, mac, linux, android, iOS, and WASM/web, each having their own HW APIs (or in the case of the mac/iOS crossover, specializations within the API). On several of these platforms there are also massive variations in bluetooth radios, which can cause a huge array of issues.
Each device may have variable actuators, or may also have sensors to take input. They may also require their own keepalives or other specializations specific to their protocol or brand to manage connections.
We then have to generalize commands to make life easier on developers. They send us those generalized commands, from whatever language they like since we abstract into an IPC system and provide a language-agnostic protocol spec, from whatever interconnect they want to use because our connector system is also violently flexible, and we have to convert them into the correct protocol and ship that over the correct bus.
So, since you're curious about why your solution for one device from one brand running through a web browser differs from my library, there you go. It's just a matter of different goals.
Now, if you can do all that in 10 lines, fantastic, I look forward to your library as competition in the future. :3
While I'm glad you've found a solution that works for your case, I can't tell you why you were seeing latency in our library that wasn't also in the browser. I'm well aware of the JS-to-IPC-to-hardware chain in the browser (I'm the ex-device interfaces lead on firefox, worked with some of the chrome engineers on the development of the hardware focused WebAPIs too) and it's even more complicated than ours.