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.
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 ).
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.
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.
We had the discussion about too fast and inconvenient speeds with full strokes going over 500 in the event group. Was brought up by @randomus who is susceptible to this. The T-code can do 600U/sec but it does not really feel good with most sleeves.
I advocate of using the index finger of you script from 100% as reference not the pinky when it goes down to 0% when speeds get really rough. Or if you script endpoints to 0% use the pinky as reference. That way speeds could translate better.
600u/s is a limit for guidance. If your actions go beyond it, thereās likely something off. In reality I keep things below 500u/s and only go beyond it on certain occasions, most of which arenāt a full length stroke.
Well full stroke in HJ is normally index finger at 100% and after hand went down on belly side pinky at 0%. You set a point for those two, thatās what you normally script. The full range. Now script index to index if things get rough and you get something 100%-50% range.
).