4 ms·

I notice very significant latency with my Moonlander Mk1, but that is most likely caused by the software and fancy layered kemaps I have created. When I use th

I notice very significant latency with my Moonlander Mk1, but that is most likely caused by the software and fancy layered kemaps I have created. When I use the Moonlander, mainly for development, I end up typing a lot slower but producing the same output. I also have a lot fewer keyboard shortcut contortions, so my hands are happier. Still it feels like we are trying to maximize the wrong thing, especially when writing software. It still feels very low level and mechanical, when the concepts and patterns are pretty well established. We just don't have a great interface for calling those up and making minor adjustments to suit our specific need. I haven't used copilot, but from seeing devs on Youtube who have it enabled, I'm not sure it is the answer. The visual distraction from seeing possible but often slightly wrong solutions appear and then change seems like trading one chore for another.

Arrath 4y ago
> I haven't used copilot, but from seeing devs on Youtube who have it enabled, I'm not sure it is the answer. The visual distraction from seeing possible but often slightly wrong solutions appear and then change seems like trading one chore for another. This feels reminiscent of my experience with most search systems, whether its the start menu in windows or google search: -Type the first two or three letters of what I want What I want appears first in the list -"Oh good", I think as my brain processes that but I still type the next letter as I was already in the process of doing so -Search results change thanks to that letter at the same moment I hit enter -Annoyance -Fin
- michaelteter 4y ago
  > Search results change thanks to that letter at the same moment I hit enter This happens so often, everywhere - browsers, spotlight, mobile keyboards, etc. When Spotlight is behaving itself, it tends to work really well. But it has bugs (or inconsistent wrong behaviors) that cause it to sometimes suggest web searches instead of the app I was trying to launch. And there seems to be no way to actually, completely disable web search from Spotlight. What does work really well is the JetBrains IDE open-anything search. Not only does it do a good job with normal typing, but if you remember to just type some of the letters of the thing you want to open, in sequence, it amazingly chooses the right one. "ores" -> OrderRefundService.
rollcat 4y ago
> I notice very significant latency with my Moonlander Mk1, but that is most likely caused by the software and fancy layered kemaps I have created. I'm not noticing all that much latency with my Ergodox EZ, but I'm also running QMK master[1] (rather than ZSA's fork via Oryx). It would be useful to note the firmware + revision in these tests. 40ms sounds like a lot of latency for twitchy games like StarCraft II (for which I've extensively customized my layout[2]); while I'm definitely enjoying the improved ergonomics in the game, I'm starting to wonder how much it's actually impacting my performance. [1]: forked to https://github.com/rollcat/qmk_firmware https://github.com/rollcat/qmk_firmware [2]: https://gist.github.com/rollcat/8b8dcd36c0abccf430b4160ad899b879 https://gist.github.com/rollcat/8b8dcd36c0abccf430b4160ad899...
- ajolly 4y ago
  Would a faster microprocessor help, or is it something more inherent? I'm just starting to get into custom keyboards. Is ZSA's build known to have latency issues compared to QMK?
  - rollcat 4y ago
    > Is ZSA's build known to have latency issues compared to QMK? ZSA is using a patched QMK - they even let you download the exact source for each firmware build they make for you. At the time when I switched to vanilla QMK (that was already some years ago), ZSA were veeery far behind master; running the latest QMK release fixed a couple of issues for me (like hotplugging the halves), so I guess there could be other improvements? No idea really. > Would a faster microprocessor help In the MCU world, latency and clock speed can have a very linear relationship - until they suddenly don't. The microcontroller's job is very simple really: scan the key matrix at a certain frequency, perform key debouncing, compare the current state with the previous, and craft a USB HID packet with key press/release events. So having twice the clock speed could theoretically let you scan twice as often, so it might let you cut the latency in half. Except we have those pesky physics getting in our way! For simplicity let's assume we don't have split halves (where there's an extra serial connection slowing things down); I'm no EE so I only grasp these concepts at the surface level, but signals take time to propagate, and long traces on the PCB (and cables too) have a tiny bit of their own capacitance. (Capacitors are like really fast, really tiny batteries - but they still take a tiny amount of time to charge and discharge, which does all sorts of interesting things to high-frequency signals.) On top of that, the electrical connection that the pieces of metal are making inside the switch, are never perfect at the exact instant the switch is supposed to (de)register: a couple electrons might start jumping over the air even before contact is made, and the physical connection is subject to normal wear, amplifying the "edge case" effect over its lifetime - which all together means we have to actually spend a certain amount of time "looking" at the state of the switch, to let it settle and make sure we got it right. We end up spending so much time letting physics do its job that in a trivial firmware, the MCU is actually spending a significant amount of time... just sleeping. Which means we were later able to cram all sorts of madness like individual RGB lightning or status displays, and never decreased the poll rate. Where would these 40ms come from then? Well I wouldn't get near the problem without an oscilloscope, and unfortunately I don't have one. > I'm just starting to get into custom keyboards. Then I recommend studying the original ErgoDox firmware & build instructions! It's extremely straightforward compared to a beast like QMK, which actually uses a whole RTOS. https://www.ergodox.io/ https://www.ergodox.io/; https://github.com/benblazak/ergodox-firmware https://github.com/benblazak/ergodox-firmware

Arrath 4y ago

> I haven't used copilot, but from seeing devs on Youtube who have it enabled, I'm not sure it is the answer. The visual distraction from seeing possible but often slightly wrong solutions appear and then change seems like trading one chore for another. This feels reminiscent of my experience with most search systems, whether its the start menu in windows or google search: -Type the first two or three letters of what I want What I want appears first in the list -"Oh good", I think as my brain processes that but I still type the next letter as I was already in the process of doing so -Search results change thanks to that letter at the same moment I hit enter -Annoyance -Fin

michaelteter 4y ago
> Search results change thanks to that letter at the same moment I hit enter This happens so often, everywhere - browsers, spotlight, mobile keyboards, etc. When Spotlight is behaving itself, it tends to work really well. But it has bugs (or inconsistent wrong behaviors) that cause it to sometimes suggest web searches instead of the app I was trying to launch. And there seems to be no way to actually, completely disable web search from Spotlight. What does work really well is the JetBrains IDE open-anything search. Not only does it do a good job with normal typing, but if you remember to just type some of the letters of the thing you want to open, in sequence, it amazingly chooses the right one. "ores" -> OrderRefundService.

rollcat 4y ago

> I notice very significant latency with my Moonlander Mk1, but that is most likely caused by the software and fancy layered kemaps I have created. I'm not noticing all that much latency with my Ergodox EZ, but I'm also running QMK master[1] (rather than ZSA's fork via Oryx). It would be useful to note the firmware + revision in these tests. 40ms sounds like a lot of latency for twitchy games like StarCraft II (for which I've extensively customized my layout[2]); while I'm definitely enjoying the improved ergonomics in the game, I'm starting to wonder how much it's actually impacting my performance. [1]: forked to https://github.com/rollcat/qmk_firmware https://github.com/rollcat/qmk_firmware [2]: https://gist.github.com/rollcat/8b8dcd36c0abccf430b4160ad899b879 https://gist.github.com/rollcat/8b8dcd36c0abccf430b4160ad899...

ajolly 4y ago
Would a faster microprocessor help, or is it something more inherent? I'm just starting to get into custom keyboards. Is ZSA's build known to have latency issues compared to QMK?
- rollcat 4y ago
  > Is ZSA's build known to have latency issues compared to QMK? ZSA is using a patched QMK - they even let you download the exact source for each firmware build they make for you. At the time when I switched to vanilla QMK (that was already some years ago), ZSA were veeery far behind master; running the latest QMK release fixed a couple of issues for me (like hotplugging the halves), so I guess there could be other improvements? No idea really. > Would a faster microprocessor help In the MCU world, latency and clock speed can have a very linear relationship - until they suddenly don't. The microcontroller's job is very simple really: scan the key matrix at a certain frequency, perform key debouncing, compare the current state with the previous, and craft a USB HID packet with key press/release events. So having twice the clock speed could theoretically let you scan twice as often, so it might let you cut the latency in half. Except we have those pesky physics getting in our way! For simplicity let's assume we don't have split halves (where there's an extra serial connection slowing things down); I'm no EE so I only grasp these concepts at the surface level, but signals take time to propagate, and long traces on the PCB (and cables too) have a tiny bit of their own capacitance. (Capacitors are like really fast, really tiny batteries - but they still take a tiny amount of time to charge and discharge, which does all sorts of interesting things to high-frequency signals.) On top of that, the electrical connection that the pieces of metal are making inside the switch, are never perfect at the exact instant the switch is supposed to (de)register: a couple electrons might start jumping over the air even before contact is made, and the physical connection is subject to normal wear, amplifying the "edge case" effect over its lifetime - which all together means we have to actually spend a certain amount of time "looking" at the state of the switch, to let it settle and make sure we got it right. We end up spending so much time letting physics do its job that in a trivial firmware, the MCU is actually spending a significant amount of time... just sleeping. Which means we were later able to cram all sorts of madness like individual RGB lightning or status displays, and never decreased the poll rate. Where would these 40ms come from then? Well I wouldn't get near the problem without an oscilloscope, and unfortunately I don't have one. > I'm just starting to get into custom keyboards. Then I recommend studying the original ErgoDox firmware & build instructions! It's extremely straightforward compared to a beast like QMK, which actually uses a whole RTOS. https://www.ergodox.io/ https://www.ergodox.io/; https://github.com/benblazak/ergodox-firmware https://github.com/benblazak/ergodox-firmware