This is not Scripts category so put your pants back on.
I’m curious to see how much of a difference a “detailed” script can make compared to a “simple” script when running on the Handy. So there goes an experiment and here’s the footage.
Handy Firmware 3.0. Running under Wi-Fi connection.
Carrot.
Notes
1. When I say “simple” script I meant the most basic scripts with top and bottom points only. Some scripters may have different standard for “simple script” such as @99DM, who makes simple versions that includes in-between points, but with limited frequency.
2. After 00:50 i’m kinda just showing off the stunts that could be done with script cached via Wi-Fi connection. Though the last action at 00:59 was actually executed incorrectly, pointing to the limitation of hardware.
3. The carrot has been cooked and properly consumed after the test.
That’s real interesting.
Thanks for the case study on this. Definitely see why detailed is better, at least when used for lighter / smooth actions or occasional bumps, such as 0:43.
You’re Right
my simple version, There was a lot of trial and error.
I made it acceptable interval limit (ex.100 ms) is set and made For Bluetooth users or other devices users.
In that state, I added acceleration as much as possible
so it’s not only Up&Down script
There are quite a few people who want a simple version other than this, so I tend to add it as much as I can
Because the two scripts are quite different, It takes twice as long to make two scripts😅
I think one thing to keep in mind is that under Bluetooth every command will result in a noticeable stutter. So for an stroke to be smooth and continuous, there should be no speed changes in it.
I hope one day people no longer have to make another script just to cater connectivity differences😅
If you happen to have a Keon, make a comparison video for that too with the same script. It will be much clearer for the users to understand the difference, and why their a script can feel bad on a Keon, and be thinking it’s the scripter that’s bad.)
This is something I’m eager to do. I don’t have a KEON however. If anyone would like to film a footage of different models running the same script it will be appreciated. I can edit the video together for a comparison.
Yet bluetooth at the same time can perfectly playback audio which contains significantly more positional information.
This is realy down to how companies dont bother to improve bluetooth connections. And the worst part on that is, even if 1 companies does, if the other side doesnt… you are still going nowhere.
For smooth information, the handy would need 1000 calls/s with 7 bits of precision. Which is about 8kbit/s (basicly 1 byte per position). Audio already exceeds that requirement. But for some reason, they cant get this to work for it? This just sounds like the used protocol is massively outdated. And most likely the standard for bluetooth was never updated for this.
These speeds were already reachable with audio almost a decade ago. But i guess the only reason those companies didnt bother improving their bluetooth standard was either because they have wifi available, or because they just couldnt bother (let be real, no women can vibrate at handy speeds)
Video
Info
Ingredients
Notes
Related Discussion