shift, ctl, alt?

[catfoobar]

Great project.

Context, C coder fumbling with python : ) Was wondering what the intention was for the single shift, ctl and alt buttons. Assumed it would work as a 'normal' keyboard, but was surprised to find pressing any of them by themselves cause the code to break. A NameError (below, pressed 'i', then 'l_shift') :

Change in state detected on pin board.A3 to off (last value was on )
Change in state detected on pin board.A3 to on (last value was off )
current_key_comb (False, False, True, False, False, False, False)
Sending text: 12
Change in state detected on pin board.D5 to off (last value was on )
Change in state detected on pin board.D5 to on (last value was off )
current_key_comb (False, False, False, False, True, False, False)
Sending text: 226
Traceback (most recent call last):
  File "code.py", line 401, in <module>
  File "code.py", line 370, in update
  File "code.py", line 383, in onstatechange
  File "code.py", line 297, in send_chord
NameError: local variable referenced before assignment

Code done running.

Adafruit CircuitPython 9.2.7 on 2025-04-01; Adafruit Feather ESP32-S3 TFT with ESP32S3
>>> [A

Without thinking too hard about the code, I put a key_buf = '' (null) above the offending line, which avoids the crash, but still seems to not do anything expected. Yes. I still do need to decompose the code to understand it better. Was wondering if there is any more documentation somewhere that might help?

Also, noted some commented out code ( kb = Keyboard(usb_hid.devices near the front, and three instances of calls to send_kb_report()). Were these simply to disable keyboard function via USB? So the device just remains in portable/practice mode?

Again, great project. And congrats for winning the contest. I really believe chorded keyboards are going to be big deal (eventually) - it's a perfect application for wearing display glasses, which are getting better and better to code on. Being able to use a portable pocket keyboard to touch type is why I duplicated your project. I have prescription lenses inside the glasses and touch type with a normal keyboard on my lap. But I don't want to drag a normal keyboard around with me all the time. This is perfect. Would be happy to contribute once I understand more about what's going on : )

[catfoobar]

Update, looks like key_buf needed to be declared as global in send_chord, which I included in the code. It doesn't crash now. But the question still remains regarding the function of the shift/ctl/alt keys. I was sort of expecting shift to be a modifier that would then be applied to the next (or next several) characters coming down the pipe. Like, 'a' would result in a 'A' being sent.

[mikeysklar]

I like your thinking. The transition from monitors to glasses is coming fast. I've actually designed several more chorded keyboards and made some changes to lower latency. The goal being 300 wpm with two handed chording.

I've not worked out the ctrl / gui / alt / shift. I'm leaning towards layers to make a clearer chord table. The current code doesn't lock and send the modifier correctly. PRs are welcome.

This is my latest hardware I've been working with called c7k (Chording 7 Key) which has a much faster response time and is I2C based. I wanted to decouple from a specific controller for easier BLE, WiFi or just direct USB-C access. I'm working towards a c7k standard this month. It is inspired by how well ARTSEY has arranged their layout, but unfortunately that format is not conducive to mobile use.

[catfoobar]

c7k looks good - great to decouple using i2c. Love the ambition of 300 wpm.

Was thinking, depending on how my experience goes with adapting to chords, once the python code is functioning well enough, I'd probably want to retool the entire thing in asm/C. That would give new meaning to 'snappy'. My (long) career is embedded SW, so, I'm using python like a weird sandbox. This kind of abstraction is really uncomfortable for me. It blows my mind we've gotten to a point where running an interpreted language on a nominally embedded micro is a thing. I do absolutely recognize it lets you play really quickly - it just seems really really heavy for such a fairly simple task. This all could be done on a 25 cent PIC. Pardon, my engineer is showing...

That said, I'll continue improving my python and intend to chip away at helping make the modifier keys do what they do on a 'normal' keyboard. It'll slow things down a bit since they'll have to be serially entered, but I'd really like access to as many key codes as possible to make it functional for running things like vim. I love coding and want be able to do it untethered. Also interested in eventually combining right and left hands. But now one is good, preferable really - I still need the other hand to steer the bike : )

In parallel, I'm thinking of 3d printing some ideas for packaging mods - although Bubby is a miracle of compact beauty, it doesn't fit my hand very well. I actually went down to the local craft shop and got some clay to play with. I molded it into different shapes and stuck the buttons in where they felt more natural. It's been a fun diversion. Sounds like you've been doing similar things.

[mikeysklar]

You have a lot of good ideas.

If you would like to help with putting together a chording 7 key standard interface I think that would help others. The SAIE layout used here prioritizes the the high frequency keys to minimal key presses.

eg. 'a' takes one key and 'z' requires four.

Sadly, there is nothing in terms of key locks and layers documented so that is all missing.

I agree that a low cost controller can achieve all this. I've been offloading to the MCP23008 for I2C and watching for buttons. It relieves the main controller from having to loop around and the interface is already faster than my daily driver qwerty over BLE.

It will be interesting to see what you come up with ergonomics. My experience has been that something to press against, grip or help balance is necessary. Chords are hard to enter if there is any slip in the grip.

I'm a VIM user also so we share the same goal to code untethered.

Find me on signal. @mikeysklar.66