Middle Points and Handy's Bluetooth Compatible Scripts

[Falafel]

動画の複数回ループ編集の簡単なやり方 - TheHandyいいよね / OG9 - Ci-en（シエン）

The following content is extracted from a Ci-en article by OG9. Translated to English. Apologies for not asking for permission before reposting. I just thought this needs to be known by more script creators.

The following content only applies to the Handy firmware 3.

---

Bluetooth (BLE) Versus Wi-Fi

When using The Handy with Bluetooth (BLE) connection, the movement responds immediately when you start playing the video or even when you seek, but for each point there is a very small delay that is almost unnoticeable (around 16.6 to 33.3 milliseconds based on my experience).

With a WiFi connection, there is almost 10 seconds of buffer time when you start playing or seek, even with a local WiFi connection. However there is no small delay after the script has been cached, which means the actions will play out smoothly.

@qdot

The Handy Wifi protocol loads most of the script to a toy, then just sends timing and playback updates to scrub to timing locations on the device. The handy bluetooth protocol sends commands one-by-one as they come in, which, with the inherent latency in Bluetooth LE, causes this lag.

BLE’s “Micro-Stutters”

The aforementioned delay with the BLE connection usually doesn’t bother me at all. But if you use a script that has an intermediate point in the middle of the stroke you will notice a momentary pause after this point.

About This Middle Point

Middle points are usually added to reflect a change of movement speed within a stroke. The need of middle points usually rises when there is exaggerated movements in the video played by skillful actors or animators.

(This wasn’t so much the case when I first started using TheHandy, but after having it for a long time, I started craving these detailed movements)

This kind of mid-point is Bluetooth-friendly. There is hardly a noticeable difference playing it via BLE or Wi-Fi.

This kind of mid-point is tricky. With a WiFi connection, it feels comfortable with a smooth change in speed. But I’m a little worried playing it via Bluetooth.

*Also, it is not necessary to plot middle point just to match every frame of the video. (Only do it if the speed change is noticeable and purposeful – Falafel)

About Very Short Strokes (Vibrations)

Also, short and high frequency strokes, aka “vibrations”, can play out differently via Bluetooth connection.

There’s 66.6 milliseconds interval between each points.
I only use this at the cum section of a video.
At this level, you can enjoy it via BLE connection without feeling any difference compared to Wi-Fi.

Here, the interval is 33.3 milliseconds.
This is rarely used, but may be useful for emphasize moments such as intense fellatio, vibrating inserts, or intense cumshots.
The movement plays out quite differently between BLE connection and WiFi connection. (I try not to use it too much as a result)

NOTE: If you are using ScriptPlayer, Make sure to set the “Min Command Delay” to 1ms. Or these strokes will be skipped!

Summary

For the mid-points and vibrations illustrated above, I’m usually in for the latter ones. But sometimes it is difficult to use them via WiFi connection because the video is very short. Bluetooth connection become useful in these situations because it allows for seamless looping within the player software. For these videos, it can be useful to make scripts that’s more Bluetooth-friendly.

But of course, you can also edit the video yourself and loop it and the script several times to enjoy them via Wi-fi. The elaborated movements may be worth it.

---

An Additional Note on Bluetooth

Whereas the Handy’s BLE implementation being pretty limiting (as well as many other device such as the KEON), Bluetooth 5.1 has proven itself to be able to transfer data at sufficient frequency to smoothly represent actions. Sadly none of the commercially available devices are using it.

[krich]

This one the few posts that helped me some on this issue, least one with actual information, instead of speculation. I thank you for that.

I’ve read this before. Then found other info with people suggesting max length between points to be 100ms on BLE, 50ms on wifi. Which seems like an estimated calculation, than a true calculation. Its the same with max speeds really, no concrete info. It is all over the place 400-620ms, for handy. Lot less info for Keon. I have no clue where these numbers even come from besides the 400ms.

So I tested myself. I found most of my issues with keon/BLE was due to the script player not on 1ms. So it would literally skip movements, like you said. I assume this feature of the player is for latency issues. But for me, it basically handicapped my experience. Especially cowgirl and she bounces at bottom, I’d miss that slight bump/single vibration a lot with 1ms.

I know that not all BLE adapters are the same. Even ones supposedly rated the same are not the same. I know this from emulating nintendo switch/controllers to PC. Only a few dozens BLE adapters were proven to be reliable. Almost none of the version-5 ones worked, seems that spec is all over the place. I bought a version-4 but can’t tell you the exact make(it is a ugreen), been to long(7+ years ago, things might of change, doubt it though). I just know they are not all made the same, some wont connect easy to certain devices, others add to much latency.

Now I do get micro stutters. Which for me, is more due to the speed of the script. Than to many points. In your second example, I’ll add 2 more points and it still shows that movement. So cut the height in half on a script, same speed but less travel. Found it had a lot less stutters when changing movement.

I’m sure BLE adds to the issue, but I don’t think its the only issue, but rather a bigger part of it maybe?

Now with BLE, Ive noticed out of sync times once a blue moon. Then on replay, its gone. Which makes me feel bad for internally rating a scripter, when it could of been my BLE issue. Someone using a vacuum cleaner, microwave, any strong/big fan in between adapter and device, HAM radio. Will all cause a hiccup, even with wifi.

One thing is for sure. I’m NOT doing BLE on my next device and WONT buy one only using it, from now on. Always hated BLE anyway. RF is superior on PC.

This is all my personal experience. No concrete numbers, just like most everybody else :]. I would, but lack any means to track the speed.

So been making 3-5 versions of scripts lately, to get more a “feel” on it. Each one doing the same time frames, but different detailed movements. At same time, feel such testing is not worth the time. Since everybody has different devices and I know an OSR2/SR6 would just do it. Like why do I bother, when I know my device is just flat out inferior and there is a superior option available.

Even from a scripters perspective… If I make scripts for osr2/sr6, then I can easily dumb them down to valleys/peaks for lower end devices. The player itself should do this, its not hard. Select all, select middle points(once or twice), delete… Done. So yea, not sure. Guess I’m just doing it, because this is what I have in mean time.

[Falafel]

I’m glad to see others caring on the issue. Thanks for sharing your experience.

To be honest, there’s too many variables at play and it’s hard to come up with a fixed conclusion. The only way to know is to gather all commercially available models together and perform some scientific measurement.

The reason why I’m recommending in other topics is because it strikes a sweet point. It is not to say I believe one shouldn’t go beyond this level of detail. In fact, some method of scripting (such as motion tracking) already generates curves more detailed than this, and it become an labour to dumb them down (just to accommodate certain devices).

@krich

If I make scripts for osr2/sr6, then I can easily dumb them down to valleys/peaks for lower end devices. The player itself should do this, its not hard. Select all, select middle points(once or twice), delete… Done.

This is also something I have been doing, especially when I poured too much effort into a detailed script that could possibly feel bad on low-end setups, and I too hope it can be achieved on the player side, a toggle for “compatibility mode” or something. Of course a lot of details will be lost, but I guess that’s the trade-off.

---

@krich

One thing is for sure. I’m NOT doing BLE on my next device and WONT buy one only using it, from now on. Always hated BLE anyway. RF is superior on PC.

I would like to point it out (to others) that Bluetooth is a technology well capable of the task, and engineers shouldn’t shy away from experimenting with it. There has been DIY t-code devices using BT5.1, outperforming any commercial strokers available.

Companies are adopting server connectivity whilst shitting on Bluetooth as if it’s some kind of inferior technology. It is not true and isn’t benefiting consumers.

[roa]

So conclusion is stay above 33? In the max speed topic the workaround was posted to set max speed to 33 and then see what is white (below 33) and those you should change. White unchanged speed is legit.

how is this different in BT and Wifi? Should work on both no?

[Falafel]

@roa

So conclusion is stay above 33?

Speed (33 unit/s) or interval (33 ms)? This article didn’t talk about stroke speed at all.

@roa

how is this different in BT and Wifi? Should work on both no?

In BLE some of these actions can get skipped due to frequency limitation irrc

[roa]

@Falafel

Speed (33 unit/s) or interval (33 ms)? This article didn’t talk about stroke speed at all.

Units per second. So question is above 33 Units is BT skipping or not? Wifi is not if I understand right and BT might as 33units per second may collide with 33ms? That is when a motion command is sent faster than the 33ms lag the motion is omitted and just does not happen. Or am I misunderstanding and it has nothing to do with units per sec but distance between two points? So a command can be lost by too slow/fast and two commands too close to each other?

Edit: just checked and OFS minimal interval is set to 33ms so is there a problem? To me it seems you can not set two points closer than 33ms?

[Falafel]

Here the 33ms we are talking about is the interval (horizontal distance between two points). If two points are this close, they may be omitted when played under BLE mode.
(Note this is not an accurate threshold, just the author speaking from experience. As mentioned above by Krich this is susceptible to many variables.)

The “33 unit/s” we talked about in the other topic is the minimum stroke speed. Handy can’t go slower than that without stopping due to hardware limitation. This has nothing to do with Bluetooth, it also affects wi-fi playback.

@roa

just checked and OFS minimal interval is set to 33ms so is there a problem? To me it seems you can not set two points closer than 33ms?

How spaced out a point can be placed depends on the framerate of your video. For a 30fps video it’s around 33ms, but with higher framrate you can easily place two points closer to each other. You can use the “FPS Override” feature to force this and ignore the video’s FPS.

---

In conclusion keep speed above 33 unit/s and interval above 60 ms if you want your script to be highly compatible with the Handy under any modes.

Or just do nothing - None of these limitation presents on the OSR. Might as well see that as a standard and force some changes on the Handy’s part (they promised a firmware update to address these issues last year but it didn’t come).

[roa]

Thanks for explaining. Couple of questions. So problems can come with older videos that are 24fps where the OFS safety of 33ms is too high? What if the 24 fps movie is reencoded to 30fps then the script made at 30fps, it should be legit? Used then together with the not reencoded original 24fps flic it should run fine at 33ms, am I right?

[Falafel]

No? The video shouldn’t matter in this.
But if you want to control “how often I can insert a point”, just use the FPS override feature in OFS.

If you want to make sure no actions is at risk of being omitted, keep an eye on the statistics window when you work with vibrations.

[roa]

I think I dont get what happens, or why the command is left out exactly with BT lag, the frametime and the Command time.

[Falafel]

You should only be concerned about actions being omitted if you add intense vibrations to your script, where a lot of points are close to each other. This, for example:

If these actions are too close, say, 33 miliseconds apart from each other, there’s a chance that some of them will be skipped when playing through BLE.

---

No, there’s no direct correlation between your video’s frame rate and BLE skipping actions. I only brought it up because you mentioned this:

@roa

just checked and OFS minimal interval is set to 33ms so is there a problem? To me it seems you can not set two points closer than 33ms?

There’s no “minimum interval” in OFS. You can place a point anywhere on OFS’s timeline. But by default, OFS snaps the action to the video frames, a restriction you can break by using the “FPS override” feature, or just click and drag the action with your mouse.

You shouldn’t be concerned about this for regular scripting. No performers vibrate at that pace. You only need to be concerned if you manually add in fancy stuff like vibrations, in which case it may play out differently than what you’d expect through BLE.

I can’t be bothered explaining this further. I’m not the Handy’s engineer… To save you some headache during scripting, I recommend connecting your Handy to the Internet when you enjoy the script. In Wi-Fi mode the Handy caches the script before playback, which means it won’t miss out any actions.

Alternatively, get an OSR2 / SR6. These bad boys run pretty much anything…

[roa]

@Falafel

I can’t be bothered explaining this further. I’m not the Handy’s engineer…

Of course, thanks for explaining.