dukman83
commented
2 years ago I have an almost identical issue to you. Except your Edit 2 and 3 did not work for me.
In my case, I had to bind an "escape" key i.e. "return to previous mode" on any key in the mode that gets trapped by this issue. For example, my temp mode key selects mode 6 after the specified duration and gets stuck that mode. Pressing the "escape" key in the trapped mode returns me to the previous mode. However, pressing the temp mode shift key for the specified duration again repeats the fault every time.
The only way I got around it is by escaping the trapped mode, saving the profile, loading a different profile which also had a temp mode shift (which was also locked by this bug), activating that profile, and testing out the temp mode shift. This seemed to work and return to the previous mode upon release. Then, saving that profile, loading my original faulty profile and activating it seemed to work again.
I am also using a tempo container and have my long press associated with the temp mode shift.
Edit 1: Disregard... new day, same problem. Turns out that before applying the above workaround, I needed to (and I forgot I did this in the above process) open the config.json file in the "joystick gremlin" directory and change all profiles' "last_mode" variables to the default profile (in my case from the stuck mode 6 to mode 1) and saving the file, re-launching JG, selecting the appropriate profile, activating it and and testing it out with the temp mode switch again. That seemed to work.
neok23
I had set up a profile with three modes, a default one and two which are activated via temporary mode switches (virtual toggle buttons which I configured in the VKB software). This setup has worked swimmingly for the past few days, but lately I find that the mode does no longer switch back to the default one (though switching between the two other modes is still possible). I replicated this issue with a clean testing profile using only stick inputs which you may find attached. Occasionally, the temporary mode switch regains its functionality seemingly at random (potentially caused by constantly changing, loading, and configuring profiles?), which then remains consistent across all profiles until the app is restarted again.
Edit: I reinstalled Gremlin but the issue is persistent. However after I edited the map to mouse python script to allow for a smaller movement delta, it started working again and persists through restarting the program. On a different note, should the shortcuts created by the .msi Installer trigger a user account control warning every time they are used (those do not appear when executing the exe directly)?
Edit 2: Something that appears to circumvent the issue encountered is to press any remapped buttons before first pressing a temporary mode switch. Enabling gremlin and engaging a temporary mode switch first consistently produces the issue, which persists through loading other profiles, and cannot be fixed by disabling gremlin. However, restarting the program, enabling a profile, pressing any remapped button and then engaging the temporary mode switch works like a charm, and even allows enabling/disabling or loading other profiles without the prerequisite of pressing other buttons first. Note that I am no longer able to reproduce this issue with the attached profile unless loading it after "breaking" the mode switch with my complex profile.
Edit 3: I am now fairly confident that this problem arises from the specific combination of placing a temporary mode switch in the long press section of a tempo container. However, it only occurs if this action is the first one activated after enabling a profile upon a fresh start. Upon occurring, it prevents any other temporary mode switch from toggling off as expected, which cannot be fixed by disabling or loading another profile (even those without tempos). It can only be fixed by a restart. Test_4.txt