Has anyone here had any successful attempts at interfacing with the handy?
I’ve been wanting for a while to make my own apps to control my Handy, but have been struggling to control the device in real-time through the existing APIs.
The HAMP protocol works OK but is just cyclic movement and doesn’t quite allow for nuance of motion.
The HDSP protocol in theory should work but is incredibly slow and seems to drop packets as many of the requests don’t do anything (perhaps I’m sending them too quickly).
I’ve even found a single Bluetooth implementation of HDSP using NodeJS+webpack (the only one I found that works on Windows), and it seems to be even slower. I thought for sure this would be the silver bullet for real-time control.
I’d like to make an app that dynamically controls the device, but the only thing I can achieve is basically setting the device into alternating motion and adjusting the min/max values and the speed, but any calls to the Handy Server has around ~150ms delay.
The only alternative I can think of would be to generate funscripts continuously in blocks, though the web API doesn’t allow for sending these, requiring them to be hosted online.
We are working on a couple of things to address these issues as we speak. The tools you have today are simply not good enough for “real-time” control. You will always have the issue of mechanical latency (it takes time to move from a-b, but the other stuff we should try to improve.
A new streaming mode. Tailored for realtime control. More on that closer to release.
Multiple servers. We only have servers in EU now, but will have multiple locations. Are you living in Benelux area today, you should have low latency, but this is something “everyone” should have.
Migrating from nodejs to Go → Well, lets just say that our backend dev speaks very highly of this move. Hopefully, this will speed up development time and performance.
Sliming our communication protocol. JSON is great in many ways, but it has too much overhead. We are switching to protobuff. That means faster processing on the device and less memory usage. In addition, the message size will reduce 40% ish, maybe even more on scripts.
Async API. Keeping the connection live through sockets will cut down more ms. in addition, it opens for notifications from the device.
FW4 is feature complete, but server connection is still in progress. Async API is not started, but should be a quicker process. If I would guess, I would say 2-3 months until Alpha, then release in 6 months ish. Trust me I want this out asap, so it might be sooner. But we have a lot of devices live, and must be sure that we do not break anything and have a solid framework to build on.
Mostly just asking out of curiosity. I’m definitely not encouraging a rushed release that could potentially impact operations. We like the Handy servers to be running smoothly. Thanks for the reply.
Realtime even with 1s latency isnt bad, simply because there are more uses that want quick responserates.
Especialy for things like games a short latency is welcome, but even at a 1s delay it doesnt matter since the game can adjust itself for that delay, making it appear in sync.
The 1s delay to me is generaly better to at least get more accurate information about following actions to avoid random stutters. A slow 0-100 movement over 10s when performed irl might otherwise become a quite stuttering effect, while if you know a second ahead what is coming, you know you are going from a 9/s to a 11/s, and can just slowly adjust its speed instead of being ‘instant’ and create a stutter midmovement. Yet if it goes quickly to a 400/s in the opposite direction, you might not even bother going to 11/s and instead prepare for that 400/s.
Curves in slow movements is something i would consider quite welcome. Even more if funscript support would be added to support such feature. Delays can make this a lot easier to perform. And since the funscripts are json based, it is possible to include this information while preserving backward compatibility (at,pos,curve - probably shortened to c). And the values to decide the curve could be like:
A small delay is on that powerful. It might be even that powerful that you might want to include it in the protocol deliberately (always knowing the desired position a second ahead).
Even when watching an online stream on a platform like onlyfans where someone is controlling your device, if that has a 1s delay it will feel natural enough. Note that a lot of gamers on twitch have a much longer delay already (often even 5 or 10 seconds). Steamers dont need to react instantly to requests of players. A 1s response would on that be fast.
Thanks for the response. If I had to cast a vote somewhere, as a developer I’d like better tools for interfacing with this device locally, as opposed to having to go through your own servers (to not only drive down latency but to ensure high traffic doesn’t lead to dropped requests). So far I only know of the hdsp protocol being available over bluetooth, but I think others have hacked around script uploading using a local server, though I’ve never been able to replicate this. Also, if any new development docs or examples come out, I hope it is a bit more cross-platform and better documented than the bluetooth example, which only works on linux.
I wonder then, with the current tools, if you can speculate how do others like “Lustbound” manage to achieve specific “patterns” of motion then? I’m genuinely curious on what the best approach is given existing tools.
How about adding local wifi api?
You really like your servers so much that you are willing to do all this work? It will probably not help that much with realtime control anyway.
Only if your game is deterministic, at which point you can just output your game movement to a funscript and send that with existing api.
Wouldn’t this be incredibly slow to have to write the file, upload it to a server, and then tell the device to load the funscript? I can think of only one way to shorten this down furth and that would be to make the game/program double-up as the file-server and skip writing the funscript to disk and serve the json using a fixed end-point… but still it would be better if we could just send the json directly to the device (why not, we’re already using a rest api which accepts json, and funscripts are in json).
If I’m missing the mark here I’d be glad to know, because I’m still curious how other people are making use of the existing APIs and techniques in this community aside from just making video players that serve premade scripts.
That’s the thing, they don’t.
The only reasonable way currently is to send the full script to the device, so if some game/app is deterministic it can upload the full script ahead of time and just synchronize the position.
Dynamic/realtime motion, like from VaM/MFP/motion generators etc. requires fast/local communication.
BLE is shit, so that leaves only wifi or serial.
I highly doubt the handy will enable wifi because they love their servers, the servers also act as script DRM for studios.
I considered trying to make a jailbreak firmware, but that would probably require having a few handys to test on, and tbh I dont care that much, OSR is much better device.
Even then, there are diffirent degrees. And truly instant responses are rarely needed, unless you are having a slider nearby to control the device. Even if doing something over a distance with video, latecy will already provide delays. And while 1s is a slightly longer delay than 200ms (which feels as near instant response), 1s allows good communication.
For games, short responses are only truly needed when its a hardcore game, or pvp. In pve, or relaxing games, a longer latency doesnt matter, since the game does take its time to show the punishement, and potentialy gives more recoveries. This allows slower transitions, which a delay can already provide.
And then we have the danger aspect. Instant responses when movement isnt there at all, especialy when it demands a fast motion, is a very dangerous thing. When movement is low, your dick can reduce a bit in how solid it becomes, a very natural thing. But enough for the handy to push it out if you are unlucky, and when that happens its dangerous.
That 1s, can be enough to get your mind to wind up and get your dick just that little bit more solid.
Idealy a combination is better, but restrictions MUST be there. Sure, when its alread doing 200units p/s motions, having near instant responses doesnt realy matter. But transitioning from a slow movement to a fast one should be somewhat predictable.
Scripts normaly already provide that. But as this is ment for a dynamic response, some restrictions need to take place. And maybe that means a 300ms delay and only 30% speed instead.
Being able to pull away when your dick isnt solid is a VERY important capability to have. You realy dont want to damage your dick.
You raise a good point, I think my use case is incorrect. Prototypes I was developing would try to generate a position value and a velocity in “real time”, and to try to make the movement less jaring I would discretize it to a smaller timestep, but hit the limit of only really being able to set the slide position once every second, which is not a smooth motion.
I guess I have to look into developing an alternative mechanism based off of HAMP in the meantime, though I’m still confused how Lustbound manages to have patterns the way it does over BLE (since to the best of my knowledge only HDSP is available over BLE)
They are in something like VaM, or MFP.
Or anything that is generated on the fly, aka not deterministic.
If you have 1s delay that means you can only send data at 1hz, at 1hz your motion does not have any detail.
MFP for example sends data to OSR at 333hz, meaning one command every 3ms. That allows near real time motion with just 3ms delay.
TBH now im not sure if we are even talking about the same thing.
What do you mean by delay? How does delay help with preventing that?
Thank you all for your thoughtful feedback and patience as we continuously work on refining and improving the Handy! We’re well aware that there’s always room for growth and improvement, and your comments and suggestions play a crucial role in this journey.
To address your specific concerns:
Longer scripts: This should be simple to fix with the new mode. You just stream parts of the script at the time. The new video player on Handyfeeling will for sure support this when we are ready.
Smoothing of curves: We’re considering providing access to specific motor settings through the API, which would allow for customization of the parameters. However, the simplest approach might still be to directly alter the script for different curves.
BLE Example: We’ve added a TypeScript BLE example in the developer docs. I hope this help.
Offline servers: While we understand the appeal of offline functionality, it currently isn’t our top priority. We’re contemplating a mode where the Handy can be set in AP mode, providing access to HDSP similar to how it works with BLE. However, we must emphasize that offline systems present significant challenges in terms of support and maintenance. An online system, on the other hand, allows us to roll out patches, make changes, and innovate with less worry about legacy support.
We recognize that this approach might not align with everyone’s preference, but our primary goal is to create products that are widely accessible and easy for developers to integrate.
As a point of reference, we are a small company compared to our competitors, who typically have higher-priced products, cheaper production costs, and greater profits. In contrast, all our income is reinvested into product development and improving our services. In fact, this is the first year that I’ve taken a regular salary, which is still considerably less than what I could potentially earn given the hours I put in…
Hit me (co-founder and CTO) up on Discord if you want a direct communication line and provide your suggestions: handyAlexander#9999
Even there, you playback a script, where even if it can cache a bit ahead, it can behave fine. So 1s isnt an issue there. And while you created it on the fly, it doesnt have to play it back instantly.
Thats a 1s interval between actions, not a delay of 1s. A delay only says that a script portion is basicly loaded 1s ahead of it being played. So density of nodes doesnt matter there. 100hz at a 1s delay just makes the 100 actions happen 1s later.
That the ORS handles 3ms is nice, but its not mandatory for things to work. And i will agree, shorter is better. But it doesnt need to go to extremes here. So if 1s is better managed, that will do fine. As again, the script it plays is still going to be the same regardless of a 20ms delay or a 1000ms delay.
The danger aspect on that is also depending on the type of stuff you do. As for example the same dangerous feature can already be performed by a funscript (but at least that can be checked ahead in time). And is something that probably can be handled by the script playing programs instead of the device. But it is something to remain aware of (due to the way the SR6 is made, risks are significantly lower here).
