Skip to content

Conversation

@iwakan
Copy link

@iwakan iwakan commented Aug 11, 2025

Added a new output device, an alternative to the The Handy output device but for devices that have been updated to firmware version 4 or above, using the new API v3.

Some problems:

  • This is a quick and dirty job, I copied code from another app of mine and quickly ported it, so the code is not clean, my style probably does not fit the rest of the application, and there's probably some unused code remnants/references. However, it does work. I did the change mostly just for myself, but I figured I'd open the PR in case you want to take it into consideration despite its flaws.

  • The new API needs to send points in advance to build up a buffer on the server. As far as I could tell this doesn't mesh with the structure of this software that sends the points in real-time to the output device class. In addition, I find that the new API needs to have points continuously sent to it to not have the buffer underrun, even if the position hasn't changed. So I implemented my own buffer and interpolation and I send points to the API in a separate threaded timer. This creates a delay of around 1s, so the user has to manually change the axis "offset" settings to compensate for the delay, for example to -1.0s, and fine tune until it matches the script. This isn't user friendly. There's probably a better way to do this, to automate the latency, but I didn't study the software enough to know.

  • The tab header isn't big enough to show the whole name of the device. I titled my view "The Handy FW4" but in the UI it shows up as "he Handy FW"

  • The new API needs an application ID, a sort of public auth key to identify what app is connecting to the API. I created an ID in my account but if you implement this device then you probably want to create your own key so that you can maintain it. Can be done at https://user.handyfeeling.com/

@Yoooi0
Copy link
Owner

Yoooi0 commented Aug 11, 2025

Yea, in the current form this is not mergeable.
The style doesn't match the codebase at all. apiAuthToken should probably not be embedded in the code. This should not be split into another output, the firmware version should be detected or be selectable and v3 or v4 handling should be done in one "The Handy" output. Also don't merge into master, always create a separate branch on your fork and merge to develop.

I think you should make a build and post it on EroScripts for people to test.

@iwakan iwakan marked this pull request as draft August 12, 2025 15:19
@iwakan
Copy link
Author

iwakan commented Aug 12, 2025

Yeah I see that. I might make a public build but like I said I made this mostly for myself so I'll see if I cba. I guess I should leave the PR open as a draft in case I or someone else ever wants to try to fix it up?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants