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!
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).
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)
1 Like
I second this. Not having control over where the strokes are shortened towards is the main reason why I am manually shortening them.
1 Like
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?
1 Like
I’ve not owned these so I’m not sure. Hope other users can contribute to this information.
They can be done well, they can also be done very not well.
1 Like
-
Script and video match 1:1
Script creator controls the maximum speed to not exceed 336unit/s -
Software handles the scaling of scripts to prevent disengagement
The scaling value is user erection length/maximum stroke of the device 115mm
For example, 100mm/115mm=86%
3.Software do not scale the action parts that are too small (for example, do not scale those <20)
Actions <20 will not be perceptible if they are also scaled
For The handy 115mm is too short. The ideal situation is at least 130mm.
The longer the stroke length, the better
Thanks for this, should be enabled at install. Found quite some areas in my scripts that were too fast.
I just want to add one OFS technique that I use to identify slow portions of the script. While you can set the max speed, there is no minimum speed setting in OFS. However, if you enter a minimum speed as the max speed (e.g., 33 units/s), most of the script will identify as over the limit, but the remaining colored script is actually under the limit. It’s a hack, but it works perfectly and will allow you to adjust any strokes (should one want to).
Example with max stroke set to 33 units/s:
5 Likes
Thanks for this hack. Problem is you have no feedback if corrected as the color marking will not change. Max speed is set to 33. Any way to refresh?
This speedchange should be OK without problems but the color stays?
Maybe turn off spline mode? I don’t have that problem when I don’t use splines.
Right Click Timeline → Rendering → Spline mode (turn off).
Before (line is below 33 units/second)
After (line is above 33 units/second)
Nah spline mode wont do the trick no idea what the problem is in my OFS. But I guess to slow isn’t as much a problem as too fast?
Depends on the device. The Tempest devices are fine slow, generally, but TheHandy and others have problems. Just to be clear, you turned off splines to check, correct? And you are using OFS 3.2.0?
Works, my bad even with splines on. Just have to watch the stats
Just because the line is long an dlooks legit to me before the marked point, does not mean the motion is fast enough per second. Thanks again.
So only lines that can stay white are the fully horizontal ones with no change at all. They are OK even if sub 33.
Edit: worked on some slow speeds and much easier to slow down too fast than accelerate slow motions. Trick seems to be to not move at all if not otherwise possible? I dont see another escape instead of making a too fast movement that just does not happen really.
Falafel what is there speed you should not exceed on the Tempest devices or just script what you see?
This can vary according to the exact build. I’d say stay below 600 unit/s, which is already very fast.
And yes script what you see - the OSRs are pretty faithful to your script. Exception is animated content which are impossible irl.
1 Like
Scripters should start making two versions of scripts then? A T-script with full motion and the Handy script, reduced to its limitations, right? Or the way round all scripts will need fixing after the SSR1 gets mainstream, which it will to what I hear coming.
The fast parts are quickly fixed, the slow parts will be hard to find and correct.
Sure you can do that. But how about make one script that’s true to the scene and let the Handy fix their software instead, as they promised above. 
1 Like
If you make a realistic script, you normaly wouldnt be reaching that 600 often. If reaching that, its usualy a handjob or animated content. Its only these actions where clipping is well noticed. The same reason to set a limit of 450 in CH videos (it does clip the last 50, but in a lot of cases the handy adjusts its timing slightly so both up down become 400/400 instead of 450/350).
At speeds of 500 you barely even notice that the handy clipped some lengths, and even more when its a variety of strokes. For such sections i generaly just script as if the handy can manage a speed of 600. Timing is a far more important aspect.
Just reducing the fast repeated area for the handy would do enough to handle these cases. And dont spend too much effort here either. Just make sure that its vertical position is somewhat right with he action (if realy reaching the bottom, make sure the script reaches there - as this is an easy to notice thing).
1 Like
Just every script I made so far hit the 500U/s for longer periods. Too slow is also a problem for the Handy why I understand is not for the SSR1.