I have not tried it myself but I have seen this mention a few times before.
I’ve talked to qDot about this as I’m in the process of creating a funscript player for Linux, and it turns out that over bluetooth, your maximum command frequency is about 10hz, which is why you’re seeing this behavior in fast scripts, or scripts with very high resolution. “HandyControl” has a feature where you can apparently host your own webserver to serve the funscript instead of HandyFeeling, but regrettably it’s closed source, so I don’t know how to set it up outside of that player; but if you could do that, then you’d get the best of both worlds: independence and privacy, and the high-resolution high-frequency performance of using HandyFeeling.
2 Likes
Huh. I thought I read somewhere awhile back that someone was able to use a locally hosted HandyControl server with ScriptPlayer to bypass the need for HandyFeeling (so doing exactly what you described) but I wasn’t able to get it to work at the time and haven’t been able to find where I read it again. Can anyone else confirm if they have successfully done this?
As I understand it currently, you can send an API request to HandyFeeling’s API that specifies the script location as on your local network; then it will attempt to download it from that location instead of you uploading it to their servers only for the Handy to download it again. While that works, it doesn’t solve any of the problems: you’re still reliant on their API even for local playback. The only real solution is hosting your own API server, but that won’t happen until they either make it available or someone reverse engineers it.
Until then, I’m trying to optimize my bluetooth script player to mitigate the command rate limitations as best as possible by interpolating high-resolution scripts to the command rate limit. While that loses a bit of haptic resolution, it’s a lot better than the stuttering you get if you attempt to play high-resolution scripts directly.
2 Likes
in fact, the guy of Handy Control already reverse engenering the api server, but the handy company add a crypto server validatión in firmware 3.x so even if you clone the api protocol you can not simulate be a oficial handy server. the only way today to upload a funscript to handy is by the handyfeeling api page.
1 Like
I’ve downloaded Intiface but when I run the installer it just completes the progress bar but stays on screen and doesn’t go on to the “finish” screen. I’m confused here.
That happened to me as well. I just killed the first install attempt then ran it again, which completed fine on the second try.
Will your funscript player be open source?
Do you have any thoughts about building for linux ARM64 devices like the RPi?
Is there any chance you could upload that edited version of Scriptplayer again? I seem to be having the same stuttering issue and just can’t seem to fix it. Trying every solution including this, but couldn’t figure out how to compile everything.
That patch made it into the beta builds of ScriptPlayer, if you just download those you’ll be fine.
1 Like
Ah I see. Thanks for the info.
I downloaded the latest release today and even made sure to update intiface, but it’s still skipping perfectly reasonable strokes and unable to handle fast patterns that are just fine over wifi. The main reason why I need to use bluetooth instead of wifi is because the gap filler function is a necessary feature for me, and unfortunately the gap filler doesn’t activate at the end of a script unless it’s connected via bluetooth.
I really don’t understand why the Handy doesn’t just have an option to connect with a usb cable. It’s not like I’m walking around the house doing chores while it whacks me off.
This is just speculation from my side…
It requires a different skill set since you have to create a Windows driver (or equivalent for any other supported operating system) and USB isn’t the most smooth standard to work with. Writing drivers is more complicated and might even require driver signing from Microsoft due to security reasons. Drivers are loaded into the core of the operating system and runs with high privileges. Badly written drivers are the most common cause for bsod:s, blue screen of death, in Windows. WiFi is basically built on standard protocols (TCP, UDP, HTTP) and as a developer you can focus your development efforts on your own software and features, not drivers and other stuff. Similar goes for bluetooth.
As has been discussed in other threads, bluetooth has speed limitations and if you are experiencing skips etc. in fast sections of a script then that might be the issue. No software updates will solve that since the limitation is in the bluetooth standards and/or hardware.
1 Like
It’s skipping in the gap filled sections. While the skips aren’t exclusive to the gap filled sections, I’m pointing this out because I can control the speed of these sections to be reasonable and I know that the strokes should be perfectly rhythmic.
Same on my end.
some videos shutter quite a bit, where on MPC player there is no issue.
Ryzen R5 3600
GTX 1050
hello, it’s ok, I did everything you said but the handy doesn’t appear for me on device
I currently have a bluetooth 5.0 dongle. I see that the newer bluetooth 5.2 offers lower latency than previous versions. Has anyone tried 5.2? I’m wondering if it would be worth upgrading to. I’m hoping that with lower latency, the faster scripts will work better
God damn, just tried this for the first time. I don’t think I can ever go back to Wi-Fi. Messing with the offsets on Wi-Fi was such a freaking boner killer.
If you haven’t tried bluetooth yet, you don’t know what you’re missing.
1 Like
TheHandy use Bluetooth 4.2. That is the “bottleneck” but should not have any effect on the speed of the device. You can use higher level bluetooth dongles but it have not any effects on the device.