Some guides and formulas you can use when scripting for the Handy using OFS

howto
1

Hey all, I noticed there wasn’t really a topic about this so I figured I’d create one.
This topic contains some useful guides and formulas that can be used when scripting for the handy in OFS.

Most of the statistics regarding the Handy come straight from their support team.
When I’m talking about strokes, assume a full up-and-down movement.
All of this is based on theoretical statistics and calculations, your personal experience may differ.

Min and max speeds

  • The minimum speed that the handy can handle without stuttering is 32mm/s.
    This translates to 0.15 full strokes per second (or ~6.9 seconds per full stroke).

  • The maximum speed that the handy can handle without the firmware capping it is 400mm/s.
    This translates to ~1.82 full strokes per second (or 0.55 seconds per full stroke).

The movement speed in OFS is not the same as the actual speed on the Handy.
This is because OFS assumes a full stroke length of 100mm instead of the Handy’s 110.
Using this given, we can calculate that the min and max speeds we can use in OFS are 32*(100/110)=~29 mm/s and 400*(100/110)=~364 mm/s..

From here on out, I will be referring to these speeds as the min and max stroke speed, using OFS’s stroke length of 100mm.

Min and max interval lengths

  • The handy can handle 10 strokes per second, meaning 20 intervals, which gives us the following:
    1000/20=50ms.
    The maximum stroke distance using this interval is 364/20=~18mm.
    Stroke lengths and intervals this short are usually not enjoyable. Performance is also influenced by how quickly the Handy can process the script. Try it before using it. I tend not go shorter than 100ms (3 frames at 30fps) using a distance of 36mm.

  • Using our max speed of 364 mm/s, we can calculate that a full downwards or upwards movement takes 100/440=0.275s (275ms), meaning a full stroke takes 550ms giving us 1.82 full strokes per second.

  • The maximum stroke interval is defined by our minimum stroke speed (29 mm/s):
    100/35.2=3.5s (3448ms) (assuming a stroke length of 100mm)

Using frames:

  • 30 fps @ 364mm/s: min=1.5f, 18mm max=8.25f, 100mm
  • 60 fps @ 364mm/s: min=3f, 18mm max=16.5f, 100mm

Calculating stroke length & interval using BPM

So what if you’re using BPM to create scripts, for example when scripting CHs or PMVs?
Let’s take a look at this formula, which uses our speed and stroke length to calculate our BPM:
60/(2(stroke_length/speed))= BPM
Using a stroke length of 100 and a speed of 364 gives us a BPM of 109. So if all you want is a full stroke as fast as possible, use a BPM of 109. This also means our minimum BPM when doing full strokes at 364 mm/s is 109.
(If you’ve ever wondered why slower songs tend to give you more freedom when scripting PMVs, this is why.)

Now what if we have already know our BPM, wanna use 364mm/s and wanna calculate our stroke length? Let’s transform the formula:
stroke_length=speed*(30/BPM)
For example, if our song is at 150 BPM and we want to use 364 mm/s, we get a stroke length of 73mm.
If your answer is higher than 100, it means your tempo is too slow for full strokes at 440 mm/s. You can combat this by halving your answer and using twice the amount of strokes.

I hope this comes in useful, if there are any additions (or if I messed up the math) let me know.

28 Likes
2

This is simultaneously pretty cool, but also makes my eyes bleed. Thanks! (This is actually nice info to know)

2 Likes
3

Nice. You can also use stroke colors in OFS to see if they exceed max. speed. As long as you don’t have red strokes you should be good to go. Also worth mentioning that red strokes are nothing bad but if you want to have a full control over Handy it’s better to avoid them.

1 Like
4

Very true, the handy will just limit the speed above the 400 mm/s threshold but by doing that it ‘distorts’ the script. Also, I guess I just like numbers.

5

However, new and better devices are released. The Handy has better specs than the Launch. Kiroo probably has better specs than Launch as well. OSR specs exceeds all of them.

If you script strictly to the capabilities of one device then the script won’t be able to take advantage of the next gen devices or devices with better performance. You still need to stay somewhat close to current device limitations and not exceed their capabilities too much because you don’t want to be completely in the hands of the firmware and hope that it behaves in a decent way. It is a balance you have to find.

3 Likes
6

Apologies for reviving a slightly older topic, but I did some testing after a discussion with @sim0nsez, and the Handy can handle up to 600 mm/s. Maybe a firmware update improved the device’s capabilities.

7

Yeah I’m personally curious about that too - I picked up scripting recently and I’ve been looking at values everywhere and I get different answers from different sources and all of them are pretty old. Some say it handles 364mm/s, some claim that the handy actually only uses 100mm instead of 110mm which also changes the whole story on how to translate it into OFS. Does anyone actually know the current state of the speed it handles + the actual stroke distance as of today? I’d appreciate that, thanks

8

Hello,
Here is what can be found on the official HANDY website:

-Variable stroke length
0-110mm (0-4.3")

-Max speed
10 strokes per second
Theoretical max speed — 1600mm/s
Practical max speed — ~600mm/s

It can be seen here: The Handy — Sex toy that revolutionizes masturbation
(scrolling down to the bottom of the page)

1 Like
9

My brain hurts, so what is the min/ max Units/S or is it the interval that these min/maxs we have to follow

image

10

Here’s the formula for OFS and Handy, without needing to know the interval.

https://chat.openai.com/share/bd4a7701-c99c-4900-835a-ac50c4006819

11

Im still lost lol , I think most of my scriptys have been ok but it would be nice to know what the limits are so I can make sure I dont under or over do it

12

Use 400 for The Handy and 500+ for the OSR as a guideline. The OSR might even be closer to 600, I don’t remember since I don’t have an OSR and target The Handy with my scripts.

The firmware of the device will shorten the strokes if the max speed is exceeded so you can script faster strokes than the device can handle. Note that there are many other factors affecting how the device will behave. Stroke length vs speed for instance (related to acceleration/retardation when changing direction), how close the points are set, wifi vs bluetooth etc.

If you ignore the speed limits completely you don’t really know how it will turn out so don’t exceed your target device too much. You might want the shortened strokes to be around the tip or the base for instance. If you deliberately put short strokes (exceeding the speed limit) at the base then strokes will be shortened around the base. If you do full length strokes that exceed the speed limit then the firmware might shorten them around the tip instead.

1 Like
13

One last question whats the shortest interval between point you can use?

14

It depends. I personally avoid to put points closer than 3 frames for a video encoded as 30 fps (i.e. 0.1 seconds). However, for sudden short movements or vibrations (short saw tooth patterns, typically 20-30% in length) I use 2 frames. This must of course be adjusted if you use a video with another frame rate. Note that I re-encode videos to 30 fps and a suitable resolution with only full frames (no compression) for better scripting performance. However, I’m not entirely sure how long series of points with 2-3 frames in between works when using bluetooth since there are limitations in sending commands to the device that way. I target TheHandy (and OSR/SR6) with my scripts that use wifi and isn’t affected by limitations set by bluetooth.

16

The min speed for the Handy is different depending on upstroke or downstroke. For downstroke, somewhere betwwen 30 and 40 units/s. For upstroke, somewhere between 20 and 30. I usually keep actions above 35 when scripting.

1 Like