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.
It has to do with the type of mechanics. Every mechanical part has a minimum treshold of friction to overcome to actualy start movement. The closer you remain to that friction point, the heavier the friction effect becomes (its not linear scale!), and the less efficient the device can perform actions.
as the handy relies on single screw for most of the actions, the speed that screw can rotate and push the carriage is what decides the minimum. These screw mechanics while relatively easy to make and being quite efficient do have a severe limitation at the lower speeds. It has a very high treshold at which it wont move anymore. Hence a high minimal speed.
The reason these mechanics are prefered in devices is because they are compact, efficient, and easy.
For a devices like the OSR which uses arms benefit from lever scaling, this minimal friction part changes. It now can decide to use gearing to scale things diffirently, as the levers themselve barely involve friction (it even needs friction to stay in place).
And there are more motors in it to apply movement, and usualy these are also more expensive. And this investment therefor does result in better handling.
The lever system also has another downside: bulk and the requirement to fix the device to something sturdy (while the handy can to some degree be handheld). Sure, its downside is also the reason why it works better. But it makes the device more limited.
But as it has more motors, it can go at far higher speeds as long as the motors were picked to work at those speeds (which they are).
These mechanics realy dont compare.
I personaly would love to have an osr2 or sr6, but i know that mounting it securely is a slight problem due to the design of my desk. Yet for the handy i can just use a microphone standard (which carries the weight using a bicycle bottle holder to set the position) with a small grip to grab the desk to prevent it moving. Something that for these heavier devices just wouldnt work.
2 Likes
Build an SSR1 then?
I remember the first OSR2+ I put together being approximately the same weight compared to the Handy. It is pretty stable on a VESA plate held by a magic arm. Though I really saved on the print infill there causing the main body to be semi-transparent.
I’ll measure it when I got it back. For your mount it may still be less stable though due to the way it moves.