WeVibe commands being queued?


I’ve been using Buttplug in conjunction with ScriptPlayer for a while now, using it with the Fleshlight Launch and with a gamepad, and everything has been working as expected. I recently tried using it with a WeVibe, but it is really out of sync and it seems like the commands are being queued, and I cannot figure out why this is the case. For example, if I’m watching a video with with a slow pace, then a fast one, the toy will continue to vibrate slowly even when the pace picks up, then only much later speed up. Or if I’m watching a video with a quick pace, and I pause the video, the toy will continue to vibrate for a while before stopping. Only the WeVibe does this, the Launch and gamepad work normally. For these reasons, I believe that my WeVibe is queueing (?) commands that it cannot keep up with (but I’m not really sure about this).

I am using a WeVibe Verge, the latest version of Windows 10, the most updated versions of Buttplug and ScriptPlayer, and the “Plugable USB Bluetooth 4.0 Low Energy Micro Adapter” (https://www.amazon.com/Plugable-Bluetooth-Adapter-Raspberry-Compatible/dp/B009ZIILLI).

Any ideas as to why this is happening? Please advise.

Thank you.

It’s a bug on our end. This is a problem with how Fleshlight Launch commands are converted to vibration in general.

TL;DR Version: Yes it’s queuing at the firmware level and we need to figure out a good way to pause before sending more commands to the toy again. This is a Buttplug problem, I’ll file a bug on the C#, it’s already filed for JS at https://github.com/buttplugio/buttplug-js/issues/27. And has been a bug since late 2017. :frowning:

Technical Version: For Bluetooth LE, the time it takes to send a message from a host to a peripheral (so, from your computer to your toy) is anywhere from 25ms to 250ms, so like between 4-20hz. In Buttplug, we send these messages “without reply”, meaning we just kind of fling them off into space and hope they get there. Think UDP. If we tried “With reply”, we lose a ton of bandwidth waiting around. In converting from the Launch messages to vibration messages, we generate a LOT of messages because we support both USB and Bluetooth vibrators. Something like 50-100hz, because technically USB could work at 1khz if not more. That whole range is far faster than bluetooth can deal with, but we never rescale our output, so queuing either happens in the OS or sometimes on the toy. Unfortunately on windows we don’t have any information about this queue, so we’re just blindly stacking somewhere. That means I need to sit down and test what a good delay is that balance between reaction time and lag.

I have a lovenese hush which has this problem with the ScriptPlayer talking to Buttplug Server.

However, the hush works FINE when Synkydink is talking to the Buttplug server.

This presumably means the problem is with the ScriptPlayer and not Buttplug.

The reason I phrased it that way is because the tuning should really happen in the Buttplug server/libraries. The system is supposed to make it so that applications don’t really HAVE to know the bandwidth and frame timing of the hardware. I think it may work in Syncydink because I fix it in the app, but the server will still take whatever you feed it.

This is why we need a new server GUI with “advanced options”, which is in the works right now.

Thats great to hear. Presumably if fixed at the Buttplug stage, the characteristics of each type of hardware could be hard coded, thus making an ‘advanced options’ only for tweaking (hopefully not necessary most of the time).?

Yup, that’s the hope.

One of the major goals of Buttplug implementations everywhere is to share a single “Device specification” file that lists identifying features of devices (names, bluetooth ids/usb ids, etc) so that we can just update that versus having to update the software every time any company we already support releases a new device. That’s another one of those “been on the todo list for ages” tasks (https://github.com/buttplugio/buttplug/issues/38), I just need to sit down and do it.