It accepts T-Code input from either a serial port or a WebSocket and outputs to the Coyote over bluetooth.
The GUI allows adjusting the frequency, intensity, etc. for both channels individually, similar to XToys but with more fine-grain control.
Channel A is mapped to axis L0 (up/down) and Channel B is mapped to R2 (pitch). Optionally if using a single axis source you can link both channels or mirror/invert the axis L0 and output that to Channel B.
It’s generally compatible with all the same tools/software the OSR2 & SR6 are.
If using a WebSocket (like with MultiFunPlayer), it does not require any additional software.
If using a Serial Port, you need to create a virtual serial using software like com0com or Free Virtual Serial Ports. This lets software like FapTap connect to COM1 and the T-Code content gets routed out COM2 to the Coyote GUI.
The source .py files are posted as well, if running from source you’ll likely need to install some pip packages.
When using MultiFunPlayer, a -0.20s offset works best due to the slight lag in Bluetooth
In rare cases, not all Bluetooth adapters work properly. Some cause the output to significantly lag (many seconds) behind the input and progressively gets worse over time. Try a different Bluetooth USB dongle if you’re having issues.
com0com does not work on Windows 11 - use Free Virtual Serial Ports.
Download:
Python source & exe compiled using PyInstaller are here:
Coyote V3 GUI:
V1.0:
Changes:
Due to the change in Bluetooth protocol for the Coyote V3 for simplicity this GUI only supports V3 going forward.
Takes advantage of the faster refresh rate of the Coyote V3 (40 Hz rather than 10 Hz). This is most noticeable in faster motion scripts.
Notes:
When using with MFP, make sure the WebSocket/Serial “Update rate” is set to at least 40 Hz to match the Coyote V3 refresh rate.
Coyote V3 does not support frequencies >200 Hz unlike the V2.
Coyote V2 GUI:
V1.1:
Fixed a bug when sending back TCode settings to host
Changed interface to control Duty Cycle and Frequency directly rather than using the X/Y values of the Coyote. When adjusting frequency it will maintain the nearest allowable Duty Cycle given whatever the required X/Y parameters must be to achieve the frequency.
fantastic, Coyote finally has funscripts done right! At least for stuff that isn’t too fast because the bluetooth packet rate for the Coyote is a little on the slow side, but if the intensity range isn’t too large it seems to handle this better than xtoys by a long shot! kudos to you, the Coyote is going to be collecting less dust for me now. Works well with MultiFunPlayer using websocket for me. I think there is something backwards with the pulse on time because the intensity is much higher if I reduce the pulse on time and less if I increase it. I remember the xtoys dev saying something about one(or more) of those values were documented in reverse in the protocol doc.
Some stuff to make MultiFunPlayer work better based on my very brief time playing with this tool - It seems like zero position on the funscript is max intensity and 100 position is minimum intensity which seems backwards but it’s easy enough to turn on invert in MultiFunPlayer to swap that around.
For two channel usage while using L0 and R2 with MultiFunPlayer - Set one as inverted and the leave the other normal and you’ve got stroking sensations if the electrode configuration is setup for it, or at least opposite behavior between the two channels connected to different places.
To bring the intensity down when the funscript stops moving(such as a long pause in an edging funscript or a break in a Cock Hero) - Enable auto home with the auto-home inside script turned on for both channels, set delay and duration to 1 second or whatever works for the funscript and set target value to 100% since that is the minimum intensity. This way both channels drop intensity instead of remaining at a potentially uncomfortable high intensity.
Hope this helps anyone else trying to get the best use out of their Coyote.
Increasing the “on” time decreases the frequency because of the way the variables are handled on the device. Since they’re inversely proportional, that’s why it seems a bit backwards.
I might change the GUI to allow adjusting the duty cycle and frequency independently rather than controlling the device variables directly.
The part that was documented backwards was the channel IDs, but it takes that into account.
To the right of that little section there is a + button next to a gear button, click that plus and you should be able to select WebSocket there from the list of about 8 options.
@Cardot hi, this software looks awesome but I am having the same problem. I can connect Multifunplayer websocket to the Coyote GUI, but the GUI will not connect to my actual Coyote. It finds it on bluetooth, but won’t connect.
Which Protocol Type / Serial Settings should I use to get the GUI to work with Intiface Central?
And more importantly: Can you add an option that pauses/deactivate the default pulse that is sent whenever no funscript is being played/no signals are being sent to the com port?
Hey!
Is there anyway to change the bluetooth name that the software is looking for? Currently it’s looking for D-LAB ESTIM1 and fails to connect as my Coyote is named random numbers and letters.
You’ll have a Coyote V3, from this looks of it this app only supports Coyote V2. I imagine the dev might be working on v3 support but no word yet.
V2 bluetooth name is “D-LAB ESTIM01”, and V3 is “47L121000”, but the bluetooth interface is totally different for the V3. The software would need a significant rework to support V3.
Working on support for V3. The bluetooth protocol is completely different. It works farily well with faster update rates (e.g. MFP sends T-Code updates at 60Hz).
Others like Faptap that use much longer time intervals between commands and are causing problems.
For VRChat OSC, I saw this: https://ga50.booth.pm/items/5801881
It comes with an .exe (Python package) called “VRCHATosc To DGLAB”.
Edit: It’s all in Chinese and it connects with the QR code to the app via Websocket.
I think directl BT conenction can be much better.
thxx
