I added OneShot.disableStickabilityForModifiers(); at the end of of setup() but after flashing the modifier keys are still stickable. The 2nd touch makes the modifier key red, where I would expect it to output the SpaceCadet character at that point. The SpaceCadet character is only output after 3 taps.
I also tried resetting the modifier keys to the default and calling OneShot.enableAutoModifiers(); but that doesn’t seem to have any effect. In fact, no configuration call to OneShot seems to produce any effects.
I even tried removing the OneShotConfig plugin, but still no dice. I am flashing the firmware through Chrysalis, btw.
This is an unanticipated use case. You’ve got a key mapped to OSM(), and you also want to use that key to produce printable characters with SpaceCadet, which strikes me as illogical. Here’s what’s going on:
SpaceCadet processes key events before OneShot (regardless of their relative positions in KALEIDOSCOPE_INIT_PLUGINS()), and ignores the first toggle-on of the OSM key because it’s not a key that it’s configured to look for. Then OneShot sees that event and changes the event.key value to Key_LeftShift (for example). The second tap causes SpaceCadet to recognize to delay the processing of the toggle-on event, and then change the event.key value to Key_LeftParen (assuming that’s what it’s mapped to). But when OneShot sees the event, if it has “sticky” modifiers enabled (I think “sticky” means two different things in Chrysalis and Kaleidoscope, but I’m not sure; I’m referring to the Kaleidoscope terminology here, where a double-tap normally keeps the modifier active indefinitely), OneShot keeps the key active by suppressing the toggle-on event, even if the event.key value doesn’t match the current value of the the active key. This behaviour could be changed by adding somewhat to the complexity of OneShot, but I’m not convinced that it really makes any sense to try to combine the two plugins on the same key.
Was your intention to have a single tap act like a one-shot modifier, but a double tap emit a printable character? If so, it would be more natural (and reliable) to combine TapDance with OneShot, rather than SpaceCadet.
I am not sure if this was the intent, but I created a macro that I use on my sketch to switch between activating OneShot or SpaceCadet.
There is some code on this thread explaining how I did if this is what you wanted:
On the same thread, there is a link to the sketch I use in case you want to look at it for inspiration.
Basically, I have one button that switches between the two modes, and the key changes colors as well so I know in which mode I am. I was toggling all of the OneShot functionality, but it would be easy to keep some of the functions active.
That sounds like my best bet. What is the best way to go about customizing the firmware like that? I’m still not sure if I should do all my customization in the .ino file and forget about Chrysalis, or if I can enable some plugins on the .ino file and upload it with Chrysalis (the attempts I’ve made with Qukeys for instance don’t seem to work, maybe due to the fact that Chrysalis already uses Qukeys).
To set up TapDance, you’ll have to use a custom sketch. There is a TapDance example sketch that can help with that. Custom sketches can still be used with Chrysalis; it’s not an either/or proposition. I got the impression from your earlier posts that you were able to flash keyboard firmware with a custom sketch; you don’t need to do this with Chrysalis (but you probably need to reset the EEPROM after doing so to keep plugins from reading incorrect configuration data).
Thanks for the context. I did upload a custom firmware, but one that didn’t introduce new data to be persisted - it only changed the boot glow key. I had the impression that by using Chrysalis to flash the firmware I would be safe from issues with the configuration data since I see that it saves the data and then restores it. If I understand correctly, the restored data can still be invalid if plugins are added/removed, then?
This kind of makes me want to move from Dynamic Macros to regular Macros at some point, since I risk losing those with an EEPROM reset.
