Ah I see. Chrysalis wiped own firmware because it was an older firmware version. Guess that means I’ll have to upgrade my ino manually first and then use Chrysalis. Probably not worth it for me.
Are there any shortcuts to assign keys in the editor? eg pressing “delete” sets the currently selected key to “Key type: blank > Transparent”, or a way to copy and paste a key?
No, not yet. There were a few attempts at shortcuts, but they caused more issues than they solved, so we backed them off for now. Copy & pasting a key is something I did not consider before. Can you file a feature request about that?
1 Like
Thanks sorry to drag this on, but is there a way to save down configuration into a local file? I think I’ve basically got the keyboard back to how I like it in Chrysalis (love not having to hold down prog!) but I have two other model 01’s that would need to have the same key settings.
1 Like
Not yet, but this is something that’s coming in the next version, to be released next week. #331 is the work-in-progress pull request that adds the most basic import/export functionality.
2 Likes
Chrysalis 0.5.0 is out now, with plenty of good stuff.
2 Likes
Is there a setting that turns dual use on? When I try to use “Layer shift when held, normal key otherwise”, it acts like layer shift all the time, even when tapped. I am using the “experimental” firmware sketch.
Using the experimental firmware should have it enabled by default. Can you open an issue about that, please?
This is probably the same Qukeys layer-shift bug that was reported in December, and has had a PR with a fix for it waiting since then.
@polsonst, I’m going to rebase #505 so it’s more readily usable, if you’re able to build a firmware based on a PR branch. I’ll post an update here once I’ve done it.
1 Like
Well, I’ve had a go at setting up and using Chrysalis for the first time in order to test this out, and it appears that my guess was wrong. When I flashed the experimental firmware from Chrysalis, Qukeys seemed completely dysfunctional, always resulting in the alternate Key (either modifier or layer-shift), as described by @polsonst. When I flashed the current master branch of the “experimental” Chrysalis-Firmware-Bundle, using the current master branch of Kaleidoscope, it works properly.
I thought perhaps the problem was due to Qukeys being placed after OneShot in the plugin order (it should work better if it comes first), but that does not appear to be the case. I can’t tell what’s in the firmware installed by Chrysalis, though, so I don’t have the expertise required to debug this problem.
1 Like
The Chrysalis firmware should be Kaleidoscope master & Chrysalis-Firmware-Bundle master, but it looks like I screwed something up.
1 Like
I should mention that I had a difficult time getting Chrysalis working, and the first time I flashed the firmware from Chrysalis, it ended up hanging. I don’t recall ever touching the EEPROM on my Model01 before, but it had what looked like it must have been a keymap in there already, though offset from where Chrysalis was expecting it. I reset the EEPROM after restarting it, and then things worked better, but Qukeys still failed after re-flashing the firmware from Chrysalis.
I had already done the things that Merlin did and had similar experiences, including having Chrysalis present me with a proposed keymap that was like my own personalized but with everything shifted one column to the right.
However, even after resetting the EEPROM, Chrysalis’s key dual-functionality still does not work. I only get the “press and hold” behavior, not the “tap” behavior. When I tap my delete/numpad layer shift key, for example, the red numpad LED pattern lights and the keyboard does not send a delete.
I love Qukeys and do use it on the two keyboards I am actively using. On my third keyboard, the one that I am using to experiment with Chrysalis, I am not using my own keymap sketch so what’s going on doesn’t have anything to do with Qukeys, per se, I reckon.
I think I know what the issue is (miscompiled firmware), will try to dig deeper and ship a fix soon.
I have a related question: when Chrysalis works can it tell the keyboard to run a macro when tapped and use a modifier when held?
Not really, no. This can be done in firmware, but not via Chrysalis. There will always be things the firmware can do, but which can’t be set up via Chrysalis, this is one such case.
The reason for this is that this - currently - requires custom code, and all Chrysalis does is poke at data. It can’t write or upload custom code (apart from flashing pre-compiled firmware, that is). If we had a Kaleidoscope plugin that allowed the macro+modifier combo via data only, we could teach Chrysalis to support that.
1 Like
I could rewrite Qukeys in a way that would make this possible. Indeed, the way that I implemented it in my own experimental fork of Kaleidoscope, I did exactly that. Even in that implementation, however, you would still need to define the qukeys themselves in your sketch, and Chrysalis would need to add a new Key category, à la Macros, wherein you would select an index number such as Qukeys #3, rather than ctrl / F.
With even more extensive changes to both Qukeys and Chrysalis, it would be technically possible to define the qukeys array in EEPROM, rather than PROGMEM, and change the definitions without re-flashing.
I’m not prepared to say that neither of these things will ever happen, but I can say that I have no plans to work on the changes that would be necessary, and I wouldn’t be going out on a very long limb if I claimed that @algernon doesn’t, either.
What you can do, if you know enough ahead of time, is define a Qukey in your sketch using a layer number from your Chrysalis configuration, and put a Macros key in the keymap at the same position. That should let you have a Macro/modifier key on a Chrysalis layer, though I must admit that I haven’t verified that this works.
2 Likes
Is the ino for the firmware embedded in Chysalis available anywhere?
Yes:
It looks like “Modifier when held” is not working right, giving modifiers on normal key presses. From similar problems with my own sketches using DualUse modifiers in the key map it appears Qukeys might be broken.
EDIT: It appears this problem is fixed in Kaleidescope master. It might be good to get updated firmware images into Chrysalis.