Managing Stroke Speed

[Falafel]

Scripts are meant to command a mechanical device. When scripting, you might want to make sure the actions are physically executable.

Strokes Too Fast

All stroker toys have speed limit, either coded into their firmware or capped by their hardware. Having actions that are too fast in your script will result in shortened stroke length.

In the Handy’s case, speed is capped at ~500 unit/s by its firmware (V3.2.3) under Wi-Fi mode. Actions faster than that will be shortened towards the starting position. The Handy can go faster under BLE mode.

The OSRs (OSR2/SR6/SSR1)'s speed limit depends on the servos installed, and can go way faster. When it can’t reach the destined position in time, it will have to abort and attend the next one.

I recommend keeping things within 600 unit/s as it’s already too fast for human sex.

---

Having actions exceeding these limit is not the end of the world, you just have to be careful at how it actually plays out.

From the “Statistics” window in OFS you can check the speed of the action. In the example below, speed is over 1000 unit/s. Too fast for any strokers to perform correctly.

In the Handy’s case, strokes are shortened towards its starting position, which will shorten these strokes towards the top, stroking the tip only. If we are scripting a scene with full insertion, this is not ideal.

How to fix

1. Turn on “Max speed highlight” in your OFS settings. This option highlights all overspeed strokes.
   

2. Keep things under control by keeping them within the speed cap. Reduce stroke length, and shift points if necessary.
   

The “Modify Script” feature on Funscript.io provides a visualisation of how your script’s fast actions will actually plays out by the device. You can also save the modified script if it looks good.

Always test your script before publish.

Strokes Too Slow

Some commercial strokers also have problem playing slow actions. The Handy (FW V3) for example, has a minimum cap around 33 unit/s. When a stroke sits below this threshold, you’ll notice a period of stopping before / after the stroke.

In Wi-Fi mode, the Handy’s firmware will take the liberty to change the actions so it can be played smoothly by its hardware, resulting in drastically different timing than what your script suggest.

For more information on the Handy’s behavior over slow actions, read this topic:

The Handy working at slow speeds - a scientific video study

[cover2] The Handy has a lower speed limit. But how does it behave when the actions are slower than the limit? I think knowing this could help us all to do better scripts as many scripts contain actions below the limit. So, let’s do a little study to find out! What is the specificed lower limit of a Handy? @handyAlexander should know and wrote in this thread: Handys speed is 32-400mm/s. Those limits are enforced by the FW. However, due to acceleration time, the top speed is more like 330-3…

How to Work Around it

It is not mandatory to address this issue and I do recommend that you script true to the scene. I really hope the Handy could improve their FW and model to adapt the scripts instead of the other way around. If you intend to adapt your script:

Try exaggerating the stroke length, thereby increasing the stroke speed.

You can also fill in the duration of the stroke with a bunch of points. This works for some devices.

Some people prefers adding “wiggles” and “vibrations” to the stroke to break it down into numerous small and faster ones. Whilst this may feel better for the Handy, they can ruin the immersion on devices that could otherwisely handled the stroke smoothly.

What About the OSRs?

Nah. T-code devices gets updated They don’t have a minimum speed. Go as slow as you want.

----

Contribution to this wiki-post is welcomed.

[Hyugsta]

Oh, so should I be focusing on keeping to 500 instead of 600 now?

[Lemonsplash]

It depends on what you want to achieve. There are many animated scripts out there that do have certain techniques and vibrations by design. They’re especially made for The Handy and don’t convert well to other (current) devices. I agree on most parts though.
Where I don’t agree is the minimum cap speed.

There were some issues with old firmwares from the Handy iirc, but it was about the top speed, which ended up in jerky movements, at least for me. Some update fixed it for me, but that was quite a while ago, which was strange because the Handy should have limited the strokes to its own capabilities. So you should be able to script up to 600-800mm/s max. (is where I would keep it) and also make use of OSR2 capabilities as well by that.

But: It’s not normal to have issues with going under the low speed cap though, with slow strokes as depicted in that first picture.
If I would have to take a guess, the only reason that could happen is if someone uses the Handy in bluetooth mode, which btw. never felt as intended. Wi-Fi mode was always superior for Handy and I believe it still is. There shouldn’t be issues with that speed / stroke at all.

Edit: Also we shouldn’t forget, that there may be devices in the future, that may have more detail, so the slow lines could be even more useful.
And yes, I wouldn’t necessarily put vibrations in a realistic script as well, but it’s fine for some artistic stuff / anime.

[mADsCRIPTS]

I will never use vibrations to perform slow parts, I hate vibrations, so damn unnatural.

[Falafel]

@Hyugsta

Oh, so should I be focusing on keeping to 500 instead of 600 now?

Overall, don’t go beyond 600 unit/s since hardly any stroker toy can reach that speed. If you want to target the Handy, 500 unit/s is the safe zone.

It is okay to have some strokes faster than 500 unit/s. But they will be altered by the firmware, so test and check that they are still within your expectations.

[Falafel]

@Lemonsplash

the Handy should have limited the strokes to its own capabilities. So you should be able to script up to 600-800mm/s max.

Yes this is true. It only becomes an issue when the Handy shortens the strokes to the undesired end. In the example, strokes were shortened towards the top position. If the script is for a sex scene with a full insertion, this is not ideal.

@Lemonsplash

It’s not normal to have issues with going under the low speed cap though, with slow strokes as depicted in that first picture.

My drawing my be a bit inaccurate, but it is normal. Happens with the latest firmware under Wi-Fi connection.

In fact, Handy’s firmware has been coded to do this and it has been documented that “Lower speed will result in a jerky motion”. Read the following page from the engineer:

Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.

[Lemonsplash]

I agree with you on both things.

But as to my understanding is that the Handy ‘would’ have jerky movements, but to prevent that, it’s capped from the hardware itself. So you can do slower movements, but the Handy will still cap. I never had issues with slow strokes like the one that you depictured and I know that, because I have made quite a few of them in my scripts, so if they would’ve been ‘jerky’ on my end, I would’ve probably chosen to not do them that way.

Since I changed to an OSR2+ I would do stuff a bit different today anyway, as in not waste as much time for small details like that, because I feel like the OSR is not as highly detailed as a Handy is; at least for me it does get ‘masked’ by the fleshlight compared to a handy sleeve for example.

Edit: I do remember though, there were issues with very long slow strokes, if you decide for example to use a long pause for half a minute and longer to slowly drive the handy into another position. That was never reliable for me.

[Falafel]

Did some testing. Apologies for my incorrect visualisations. It’s more of an issue with stutters. And sometimes the timing gets changed by the firmware to pursue a smoother movement.

Try running this script on your Handy if interested:
test.funscript (940 Bytes)

[Falafel]

I will definitely need a camera to illustrate what’s going on

[Lemonsplash]

So, I went and pulled out my Handy, configured it, etc.
I thought the strokes you’ve posted were the script, but turns out, it wasn’t.

Anyway, I don’t have issues with that script. How do you load and play scripts?

[Falafel]

@Lemonsplash

How do you load and play scripts?

Via handyfeeling.com and ScriptPlayer. Handy FW 3.2.3.

@Lemonsplash

I thought the strokes you’ve posted were the script, but turns out, it wasn’t.

Yes the image I’ve posted are the script content.

Most of them are executed on time, albiet with a period of stopping before or after the action (which is still not nice).

The major issue happens dring the “W” shape. There are no stutters during this section and it feels quite smooth. But if you watch closely, you’ll notice how the Handy perform differently than the scripted content.

What is scripted:

What is played:

[Falafel]

I forgot this existed:

The Handy working at slow speeds - a scientific video study

[cover2] The Handy has a lower speed limit. But how does it behave when the actions are slower than the limit? I think knowing this could help us all to do better scripts as many scripts contain actions below the limit. So, let’s do a little study to find out! What is the specificed lower limit of a Handy? @handyAlexander should know and wrote in this thread: Handys speed is 32-400mm/s. Those limits are enforced by the FW. However, due to acceleration time, the top speed is more like 330-3…

[Lemonsplash]

Ahh~ yeah it was the script just zoomed out, explains why the colors are all green and yellow. - The pictures do give a wrong impression though, so people won’t know what we’re talking about if it’s zoomed like that and it’s hard for them to compare.

Anyway, that’s the behavior I was talking about, if you do the strokes in general too long and too slow, it’s not reliable anymore, that may indeed be an issue. But on the other hand I never scripted multiple long and slow strokes like that in a script iirc. It gets more weird if more of these strokes are connected. But if you go under the cap for shorter strokes, its not an issue.

[Falafel]

Changed a lot of wording and presentation in the OP. Thanks for the contribution

[SomeoneRandom]

I noticed that the issue here seems to be that the handy is making too much guesses. This behavior is breaking a lot of CH videos currently.

From my experience, if any stroke is below the minimum speed, its ignored entirely. As a result, if you have a section end at the bottom, and the next starts at the top. It ignores the node on the top and will continue at the bottom.

However, if the section of 2 nodes together would enable a full stroke at minimum speed, it prefers doing that (hence in your example it makes a slower downstroke).

The way to resolve that behaviour is by deliberate scripting:

In this case since the upstroke is within the allowed limit, it performs that stroke as intended.

But even here, the first downstroke (if the gap is too large) doesnt perform properly. If you ask for a fast stroke, it should be fast. If the speed is too much, it should just shorten it instead.

Idealy, it should automaticly detect when to move up based on the next position. If too slow it should just wait until it can move at its slowest. The current guessing behaviour is significantly worse as it breaks immersion.

This behaviour is amplified on scripts exceeding 400ups now, as then timing is broken almost everywhere. I liked the old firmware better as at least there it kept the timing properly.

CH videos are excessively vulnerable since you have a very clear beat. So any adjustment the firmware makes breaks the timing. Timing can be noticed extremely well, unlike speed where most people wont feel any diffirence between a 350 and 400 ups stroke. It just feels like a fast stroke.

[Falafel]

@handyAlexander Great if you could shed some light onto this… Also consider these as feedbacks on the FW

[handyAlexander]

Wow! Nice discussion and excellent research.

My take is that in theory, the script should match the motion 1:1. Then there can be adapters that transform the motion into motion that fits the device. Unfortunately, most scripts are “scripted” for a device, and you have to consider the device’s limitations. There are two main factors; motor regulation algorithm and speed range. Luckily for Handy owners, the max speed is 400mm/s, and our closest competitors have a max around 200mm/s. Twice the speed, half the limitations (twice the fun?!?).

Due to acceleration, the average speed over one stroke will be at least 330-350mm/s. We are working on FW4 that will have a better motor regulator (MPC), allowing the average speed to increase without changing the speed limit of 400mm/s.

So, if you want to script for Handy:

• Keep the max to 350mm/s*96mm (max stroke) => 336units/s
• Keep the minimum to 32mm/s*96mm => 31units/s

Keep in mind that we will work towards allowing scripters to match motion 1:1 and provide adapters in the future. This way, you can just script what you see and the device you are using (Handy products, of course:)) will fix the rest.

[Falafel]

Thanks for the input! I’m more curious at the Handy’s behavior at slow action where it changes the timing of the nodes in order to play it without breaks.

@handyAlexander

Keep the max to 350mm/s*96mm (max stroke) => 336units/s

My experience tells me the maximum sleed is 500unit/s in OFS. Stroke length are only compromised when exceeding that threshold. I wonder if this is because the software calculate speed differently.

[handyAlexander]

Currently, if the speed is slower than min, the device wait for X sec and starts moving at min speed to be at pos X at time Y.

[Falafel]

Yes this is what happens, most of the time.

This script consists of 23unit/sec slow strokes followed by a 283unit/s fast strokes. I invite you to test it out. The 283unit/s strokes will be performed prematurely by the Handy at a slower speed.

test.funscript (1.3 KB)