The Taipo plumbing kind of works

I haven't been able to find the meta field in recent versions of KMK, so I've currently used a workaround with argumented keys: 

The drawback is that, if the Taipo module is disabled, the keyboard will refuse to start because "Key is not callable". Thus, you also have to go in and remove all the TP() keys in the layout and save. Today, I've had another look in keys.py and figured out how to get a non-augmented key to work, mainly by copy-pasting the boilerplate:

class TaipoKey(Key):
    def __init__(self, code: Optional[int] = None):
        self.taipo_code = code
    
    def __repr__(self):
        return super().__repr__() + '(taipo code=' + str(self.taipo_code) + ')'

Another thing I've noticed is that the layout breaks if a KC.MACRO() key is held down. I tracked down its signature (sounds like I'm a spy movie hacker writing that) and found an attribute that only KC.MACRO has:

if hasattr(state.keycode, 'blocking'): # Only KC.MACRO has this
    keyboard.tap_key(state.keycode)
else:
    keyboard.add_key(state.keycode)

Still, with these preinstalled milky reds, the 2mm actuation distance is a major issue. Both Taipo and MouseKeys doesn't mesh very well with such a deep actuation distance. I think the Akko Silver v3 Pro is going to be the best solution.

Right now, I'm in the process of creating a UK English layout and sidestepping the WinCompose requirement for unicode.

Circuitpython MemoryError

Yesterday, I was having MemoryErrors unless I turned off RGB and the ADNS-5050 modules. While still trying to solve the pan issue, I read through the changes since Circuitpython 8.2.10 and found out that MemoryError was a cited problem that could happen. Compiling and flashing 8.2.x seems to avoid this problem.

While I was there configuring circuitpython, I found that the RP2.65-F keyboard had this in mpconfigboard.mk:

FROZEN_MPY_DIRS += $(TOP)/frozen/Adafruit_CircuitPython_NeoPixel
FROZEN_MPY_DIRS += $(TOP)/frozen/Adafruit_CircuitPython_MIDI

 Thus, I looked it up and found out that it compiles the library .mpy files straight into the fabric of circuitpython:

Normally, all imported Python modules in CircuitPython are loaded into RAM in compiled form, whether they start as .mpy or .py files. Especially on M0 boards, a user program can run out of RAM if too much code needs to be loaded.

To ameliorate this problem, a CircuitPython image can include compiled Python code that is stored in the image, in flash memory, and executed directly from there. These are "internal frozen modules".

With this feature, the neopixel.mpy file doesn't need to be copied into CIRCUITPY/lib/, though it only reduced my MemoryError issue on 9.1.3 from 1280 bytes down to 294. 8.2.x has had no effect on the pan issue.

Invalid USB VID

While on the topic of circuitpython, my PR is currently blocked because WEEKIN might have made up the vendor ID. In an effort to promote open-source software and hardware, pid.codes was founded and I'm requesting the same ProductID as WEEKIN used. I will understand if my PID request is rejected since I don't have any hardware source files.

Conclusions

At the very least, I've finally got an "implementation candidate" 32 days since I discovered the WK-50.

I'm also glad that #Tetent [gd0090] is force-based not displacement-based. If I could get hot-swappable switches that moved and felt like microswitches, that would be ideal for the WK-50. Additionally, I'm glad that the layout is such that I don't have to chord with multiple fingers when starting out.