How do you like handy implementation so far?
Let me know if any specs in mind or any alternative ways of connection.
I have nothing to do with the Handy Wifi implementation because it only talks to their servers, but is also only for video sync so itā¦ kinda works for that I guess? Video sync has never really been my concern.
I convinced The Handy devs into implementing Bluetooth for Buttplug. Honestly, Iād take some on-device local wifi interface alongside bluetooth if I could get it, as bluetooth does suck even though it seems to work ok for most of my users, and weāre now on mobile. What I refuse to do is bounce network to a remote server owned by a hardware manufacturer to control a toy. Thatās why my library supports Lovense Connect but not Handyās network services or Autoblowās new networked toy. If I canāt access a toy directly without talking to an outside server, Iām not supporting it in my library.
Iām not sure why a video services company with no device communication interconnect experience is leading the charge to change/standardize connection specs, but Iām also not sure why any manufacturer is listening to you either. This feels like the blind leading the blind.
10 Likes
I have to say i have 0 problems with bluetooth and the handy. Like what so ever. I donāt know if people are just using BT dongles from a decade agoā¦ Anyways, ever since i discovered intiface i will never go back to wifi - ever.
2 Likes
Gonna say Bluetooth connection did its job right. But, there are some content thatās just beyond its capabilities.
Hereās a content I scripted earlier which I made two version for, one specifically optimized for Bluetooth. Check the difference.
Handy well has the ability to reflect the details in the 1st script. Which is unless itās a Bluetooth connection. Then it begans to skip actions due to frequency limits.
EDIT 2024: I now think this is due to BLEās limit and, well, terrible engineering. In terms of playing scripts, Bluetooth is not at all inferior to granting control of your device to a remote server.
2 Likes
IMO bluetooth was only added to The Handy so they can say they allow offline/local connection, but it is just so bad that you have to use handy servers for a proper experience anyways.
You will have 5-10hz updates tops over bluetooth, so it will only work with super basic script like above.
They could have spent the effort adding it using wifi instead, but then no one would use their servers.
There are many features in for example MultiFunPlayer that would improve handy experience like speed limit/auto home/interpolation/random motion etc. but its not possible with low/unstable update rate of bluetooth.
Any stroking device that doesnt have local wifi/serial connection is imo unusable, leave bluetooth for simple stuff like vibes.
3 Likes
@Yoooi @Falafel This 5-10hz updates thing doesnāt limit bluetooth at all. I want to point out that bluetooth is more than capable of handling the most advanced scripts with the correct firmware implementation. Case in point, the fleshlight launch, one of the oldest devices out there, which uses bluetooth.
With the stock firmware the launch canāt keep up with modern scripts at all. With the custom firmware here at eroscripts, it can handle any script youāll be able to find without issue. The difference is night and day and it shows that the limitation is not the bluetooth protocol, but the firmware. I know it can handle 30ms movements at least but havenāt tried anything faster than that. If bluetooth can handle that it can handle anything a scripter would want to do.
2 Likes
This is not a specific problem with bluetooth, or wifi. This is a caching issue.
The Handy Wifi protocol loads most of the script to a toy, then just sends timing and playback updates to scrub to timing locations on the device. The handy bluetooth protocol sends commands one-by-one as they come in, which, with the inherent latency in Bluetooth LE, causes this lag.
If the handy cached the script to the device via bluetooth (which is doable), and could deal with the bit of timing jitter theyād get for playback updates in terms of bluetooth packet timing, this would not be a problem.
5 Likes
Honestly Iām probably going to end up writing a blog post on this, as this is far more complicated than is good to get into here. This is a video sync forum, everyoneās worried about video sync, but when you get into general toy design, thereās a lot more to think about than script playback, and I think that needs to be covered alongside the issues of how to reliably make money off scripts without crippling hardware for the consumer.
Not to mention, this isnāt the first time this has happened. There was a ton of worries about script DRM from content producers in the late 00s-early 10s that led to gross things like RealTouchās always-phone-home protocol, which is why Iām so jumpy right now. I really do not want to see the industry move backwards here, nor do I like the idea of having to return to my old aggressive stance in relation to hardware manufacturers, so Iām hoping whatever is going to be done will be done correctly. That said, given the lack of engineering prowess Iāve seen from the manufacturing side thatās gotten us here, I feel like I have good right to worry.
11 Likes
Iām merely standing on the user side of things. Thanks for clearing this up!
Itās good to see that someone else sees the downside of these changes. People think Iām crazy for saying similar things to what youāre saying. Iāve pushed for handy to give us true offline wifi capability instead of bluetooth but theyāre not interested. This has a lot to do with DRM and I also understand it is a financial decision on their part based on the toy design and where they appear to be going as a company. As youāve said, this is more than can be explained here. One thing I will say with almost complete certainty is that forcing server connection is going to end up costing users more money.
I appreciate the enthusiasm from Handy users for the product and understand how a connectivity standard makes sense. However, there is a large base of users who either donāt care for the way the Handy functions or prefer another device. I still think a wider user base is a better business model, even if other devices have less dependable haptics functionality.
If we were to use the devices only for on device script playback then I agree that caching via bluetooth will work perfectly fine.
But that is very limiting, script players like JFP/MFP sample the script at high hz and send live commands, this allows many additional features which would not be possible otherwise like actual speed limit, or interpolation. All these features could ofc be put on the firmware itself, but then you also have other software like games/vam/random strokers/buttplug etc. where live commands are the only way and you canāt cache anything.
BLE is just not suited for stuff like this, it can choke at 10hz and stroker devices will be stuttering a lot, vibes dont have that issue.
Hah, glad I did not stick my foot in my mouth with a blog post quite yet then. Iāll poke you on discord to get more info on this 'cause obviously Iām behind the curve on whatās up with video sync. Iāve been off in real time interaction in VR Virtual Worlds land for the past 1.5 years, so I think we share the same concerns, but Iād like to make sure I have many understanding and language about the current state of video sync correct before I get on my soapbox.
I will say that I donāt think network connection is a bad idea overall. Quite the opposite, it alleviates many issues I have in VR with movement and radio range of wearable hardware. I just want to make sure itās approached in a way where weāre not stuck communicating with remote servers, which sounds like itād be a problem for you too.
1 Like
the OSR devices would actually be the easiest to make compatible. Add wifi module if it doesnāt have one yet, update firmware.
Itās not really that expensive even.
WiFi modules come with BlueTooth connectivity 99% of the time.
1 Like
Thereās no need to be negative. We do have the community in mind, we are adding direct TCode/OSR support to SLR (for windows) as we speak. In fact, We already have a build thatās working well.
For the first release itās going to support single axis funscripts and the edging and play/pause script bindings directly inside SLR.
2 Likes
I donāt use my handy in wifi modeā¦ Ever since the Bluetooth update I use it in Bluetooth mode exclusivelyā¦ I am not a fan of putting what infap to onto a server I donāt controlā¦ At least with custom scriptsā¦ Even filenames can give advertising companies a leg upā¦ Plus what happens when that server goes down? We canāt use out toys?
Another thing is I just want open hardware or at least something that I can fix if needed and will still work after the servers get sut downā¦
If I had more hardware reverse engineering I would have tried to reverse engineer the handy and make a customer open source firmware that allows for direct wireless communication for the real time updatesā¦
But I will be honest I have not used scripts in a while so I am not sure about the more intense scriptsā¦ (Most of the scripts I used were originally made for the launchā¦ So they are already at that slow command rate)
I just donāt want a expensive lubed up paper weight cause a server isnāt working
2 Likes
Iāve been told I am hostile in my responses. Thatās not at all my intention. You can read this in a completely informative & neutral way.
None of these things are related or even apply.
Do you see many adds on SLR? And Iām not talking about the banners that promote our own service or content partners. No one has access to our server. Other sites donāt even have their own server, so there all your info is sent to another party.
Using Bluetooth still sends the data over the internet. Unless you use exclusively local files and run your own syncing server/app.
Not sure what you mean by custom scripts. Up to this point, all scripts are custom and are not owned by SLR. The money you spend on them goes to the script creator and scene studio.
āIf the server goes down?ā I think I know what you mean Purchased scripts can perfectly be used with other syncing solutions. If youāre subscribed, you pay for access to the scripts streaming. Not the server. You donāt need a subscription to access the server.
We are not in the business of changing Internet people minds. Nor that is even possible.
We do what we think is right and let others admit they were wrong once we roll it out and everyone sees itās great.