Hey, apologies for the late reply.
High level overview of current method is there is a number variable storing the current time of the video. When a user pauses or seeks, this value is updated. Also, when the video is paused / played, this number stops / starts.
Every 50 ms, this variable adds 50 ms to itself when it’s running and then checks for any close by points in the Funscript file in a plus / minus range of say 100-150 ms apart, if one does come close by, the point is sent to the device.
It needs to be finely tuned, need to experiment with the window for a close by point, for example say 500 ms. That is something I could investigate, but what I’m more so interested in doing right now is implementing device-specific SDKs, for example the Handy SDK as some scripts for example from NaughtyAmerica, are token-based requiring the SDK to facilitate preparing the script for the device.
Unfortunately, your suggestion will probably not solve this as the issue seems to be the latency between crossing a point suitable for playing, executing some logic, then sending out that event to the device, then the device itself needs to actually do the action.
Fundamentally, the current method is reacting to available points as they become available but as we can see it’s just not fast enough. As I said, could try stretching the window, though if I recall correctly, it used to be a larger window but still wasn’t that good, will need to give it another shot.
One thing that I plan to release is Handy SDK integration. When a user adds a Funscript file, it’ll be sent to the Handy device itself. Then all I have to do to orchestrate syncing is hook in the video players play and pause events to the Handy SDK play pause function and voila. If it works well (which hopefully it does), I’ll look into the Lovense SDK as for example, you’re mentioned you’re using a Lovense toy.