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.
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.
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.
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.
@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.
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.
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.
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.
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.
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.
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
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.
That’s a bit of a stretch. Bluetooth in itself is local and only local. However, depending on how you consume your videos and scripts it may be local or streaming via Internet or a combination of them. The stroker device manufacturer is not involved, even if you stream the content, while using bluetooth. Bluetooth is therefore not susceptible to stroker device manufacturer server downtime (only content provider downtime unless using local content).
Another issue is that not everybody do what they say in their privacy policy (this is not an accusation against SLR). There have been several studies on apps declaring that they don’t share data with third parties, but when tracking network connections and data packet transmissions researchers can see that large quantities of data are sent to 3rd party IP addresses that don’t belongs to the app manufacturer, CDNs or other acceptable recipients. Given the taboo/stigma around porn in many countries privacy is a concern for many. You don’t want adult ads popping up while browsing due to your sex toys.
I believe that supporting both bluetooth (at least for local content) and wifi using centralized servers (or not) is the best way to go. A public API is also important for a niche community that scripting and software for stroker devices still are. See also the creativity and ideas around interactive games and other apps supporting user interaction that don’t really work well with unpredictable Internet delays. Internet and overloaded servers causes all kind of synchronization issues when sending commands based on user actions. It isn’t just simple timestamps that can be sent at a semi-regular interval while the script is stored in the device.
