Managing Stroke Speed

[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)

[handyAlexander]

The motor algos are written from scratch in FW4. I think it will be more interesting to test the new FW to find the new limits. Then we can also try to optimize and improve to cater for edge cases. Alpha is out this week. When the open Beta testing starts, you should join in and run the same test!

[SomeoneRandom]

@Falafel

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.

For me its somewhat diffirent. If its a standalone stroke, even a 600 stroke works fine (it doesnt reach that speed though so there will be a misalignment, but at these speeds the delays arent noticed). I think it barely matters which speed you even have in these cases as the timing misalignments wont matter and the handy goes full speed regardless.

But in a constant pattern, going above 400 will limit stroke lenghts, but often not directly noticed if the stroke afterward goes below it at a few locations. It does depend quite a bit on the used sleeve though. some sleeves have better positional feedback at certain ranges (the lips one for me has a very clear transition somewhere near the 30-20 position, making it obvious whenever it clips values below this point)

Yet, for following the action, as long as the script remains below 550 (vibration pattern with about 30actions per second), it still will work fine. The reduced lengths barely matter since you just ask for the max speed anyway and the firmware just corrects this. Even for the lips sleeve, if you use a vibration pattern, its near impossible to tell the transition (as friction/resistance now reacts diffirent).

@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.

I guess FW4 only? As the current version i have definitely doesnt do this reliably.

I will probably also run some tests with the new FW.

---

Also, i dont know if this was considered, but if strokes are too fast for the device, is there a way where it tries to align strokes a certain way?
For example if the script wants it to touch the bottom, have the strokes focussed in a way that it reaches the bottom (and clips the top). while if it asks for the top, clips the bottom motion part. (and in the middle it just clips both sides)

I think this sort of behaviour would be welcome for scripts that are too fast, yet still want to emphisize a certain location.

I even think that algorithm wise it shouldnt be too complex to make as you do know both the max reachable position, and the desired position for several nodes. And just the gap at the top and bottom are enough to make a judgement: lets say top misses 30, bottom misses 10 is enough information. In this case the clipping should be 75% on the top and 25% at the bottom.
(or you already have something better in place thats something i cant know)

[Falafel]

@SomeoneRandom

Also, i dont know if this was considered, but if strokes are too fast for the device, is there a way where it tries to align strokes a certain way?
For example if the script wants it to touch the bottom, have the strokes focussed in a way that it reaches the bottom (and clips the top). while if it asks for the top, clips the bottom motion part. (and in the middle it just clips both sides)

I second this. Not having control over where the strokes are shortened towards is the main reason why I am manually shortening them.

[Neuronix]

Thanks for explanation and hints! Very helpful. However, I’m also looking for the limits for Keon/Onyx+. Any thoughts about minimum/maximum speed of 1 move?

[Falafel]

I’ve not owned these so I’m not sure. Hope other users can contribute to this information.

[heck]

They can be done well, they can also be done very not well.