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.
In my setup its more about weight distribution, to which handy as cylinder works better. Its not just up down, but also left right that matters. Even the handy has enough force to lift the microphone stand in such way it can slide (hence a small grip is used to avoid that).
But knowing the OSR is similar to the handy means i can potentialy figure out a way to make that also work. But that only becomes relevant when my handy is starting to break down (it slowly is starting to get to such state though, but yeah, it had some abuse already 
).
1 Like
OK no more downtoning for Handy, speed maxing out at 600u/s
Something I’ve never understood is if this cap of 600 u/s for The Handy applies only for a full 0-100 stroke or to any range the stroke covers (a stroke 0-10 at full speed is hell of a lot faster than a 0-100 at max speed). I try to keep all of my scripted strokes under 600 u/s, no matter the range, but I see people like Realcumber well exceeding the 700u/s and when I use those scripts myself, I don’t feel any problem with The Handy.
On the other hand, the minimum speed causes notorious stutters if you go below a certain threshold, you can feel the device stuttering sometimes. I try not to go below 33u/s, although 23u/s is still fine if the stroke is not that long in time.
1 Like
Maybe that RC seven hundreds you don’t feel the omitted strokes as the third one is still in sync? Too slow there is no way out for the Handy. I agree with Telani that the Handy should not be what we script for, I do not any more. I want to push better devices like Tempests SSR1 so I will script for that and ignore the Handys handicaps.
The other reason is, once the handy guys sort out too slow and too fast we will adapt all scripts to now faster and slower possible? Hell no.
@Falafel why 600 with SSR1? I do hit that limit scripting.
How do you add vibrations to the stroke?
I tried to copy/paste with ctrl+c ctrl+v and it just replaces the original points
The easy way:
I’m more used to manually make the vibrations using the “addPoint” function from the Util extension. It’s a lot cleaner imo.
1 Like