QMK is an amazing project. I'm using it for three keyboards so far.
That said, tweaking the behavior of tap/hold dual function keys is voodoo. There are a few flags one can set, or one can replace the keystroke inner loop, which I'm about to do. 18 of my 30 core alpha keys are dual function, either modifiers or access to other layers. I have many shortcuts that involve one finger from each hand in sequence, easy chording. However, change keyboards and I trip over myself on fast ordinary typing, accidentally triggering sequences that rearrange the orbits of the planets. (I used to use Emacs, so I'm used to this.)
Everyone types differently, so "this works for me" rarely helps. Every mechanical switch activates differently, so one can adapt to one keyboard and be back at ground zero on another keyboard.
Scheme would be great for creating a DSL implementing arbitrary flow charts for the state transitions as keypresses register down or up, and timers fire. Writing this in C is tedious. And if chording ever "just worked" many more people would adopt it.
I am similarly having trouble with Space Cadet (where Shift sends a parenthesis when pressed but is Shift when held). It interacts badly with other keys because there's no way to tell it to never output the parenthesis.
I need to be able to stop it because sometimes I tap both Shifts (right then left) to output Caps Lock or to output "()" (left then right). Since there's no way to tell QMK "I've manually processed what I needed to process from these keys, you can stop", it sends the parentheses anyway.
It gets even harder to debug because, as you say, it's highly timing-dependent. Hold (tap) the key for 100 ms, you get one thing, hold it slightly longer and you get another.
I have a todo item to reimplement Space Cadet myself one of these days so I can override it better, but I shouldn't have to go to such lengths.
Do you believe the net effect is in any way positive, in whatever metric you’re trying to optimize for?
No offense intended.. I’m really interested in the answer. Because I, too, have spend a lot of time optimizing keyboard shortcuts and similar. But I’m nowhere close to actually using all the great shortcuts I set up, and then some new software might create a conflict and the patterns I set up need rearranging etc.
I’m probably the only one on HN who actually thinks the magic bar could be useful-to expose keyboard shortcuts in a discoverable way. There must be hundreds of actions I do less often than once a day but more often than once a week, and some method to train could really put a dent in my mouse-meters.
I'm a mathematician on sabbatical, after many years glued to a screen. I spent the first few months outside doing woodworking; I've been struggling with an overwhelming urge to center my consciousness in my hands. This is of course the history of our species, a biological urge as profound as our sex drive. We figured out how to make very sharp hunting tools from unruly rocks, or we died.
I've managed to fix myself back at my computer only by increasing the dexterity workload, making the process more interesting. Any increase in efficiency is a bonus. The reward is that I'm actually sitting here at all.
It is an astonishing sensation, accomplishing everything with slight movements, using both hands at once. As one progresses, the fire burns and other movements that were once acceptable feel ridiculous. Imagine sleeping under a half dozen haphazard blankets, always waking up feeling like you're tangled up in Saran wrap, then switching to the European system of a single Duvet as top sheet. There is no going back.
Some people have a better eye than others for cultural inertia. The classic keyboard design carries the "DOS-compatible" weight of resembling a mechanical typewriter. Is it even faintly conceivable that this is anywhere near optimal? Also recognize that most products are aimed at ease of use for beginners. In stark contrast is stenography equipment, which requires years of commitment. What is an optimal investment of energy?
I've succeeded miserably so far at what I consider an obvious goal: One should spend half one's career as a programmer developing the skills so that one can then do the work of ten people. I am forced to tolerate my failure here, but I can't accept that most people don't even see this as a goal.
A related debate is vim or emacs editing. It's trying to scratch the same itch. The question isn't comfort, but maximizing bandwidth between us and machines. These editing systems are crippled by the keyboard interface itself, and then one uses them through a periscope: One works in a terminal session where even multiple windows are drawn with dashes like a second-grader wielding a crayon. If one instead programs many QMK layers, the fingerings spread out and are much easier: One finger from each hand near home row is much easier than emacs control-xylophone for anything, again I feel tangled up in my sheets. And the target becomes one's entire operating system, not just an editor window.
Any advice for getting started in QMK? I'm an experienced programmer, so every tutorial that starts with git and the basics of C is frustrating, but I don't have a lot of experience with hardware, keyboards, etc.
For example, I have no idea what "keystroke inner loop" you're referring to - where can I read more about that?
The docs for using QMK are pretty good, but trying to actually understand the code made my head spin; that's why I decided to write my own firmware. Right now it doesn't have any of the fancy features of QMK, but it currently clocks in at under 200 lines, so I have a suspicion it'd be easier to implement those features from scratch in Microscheme than understand their current implementation in QMK.
There's a middle ground. One wants to take advantage of the prior work supporting all these keyboards, while improving and/or making more understandable the core keystroke processing logic. Develop a user language for this logic, that translates to C code that can be included in QMK?
If the root problem with QMK is that there are too many moving parts, adding a completely new language and compiler into the mix seems like a step in the wrong direction.
The extra features that QMK has and Menelaus doesn't aren't really all that appealing to me to begin with.
Reading the documentation is a good start, but one needs to experiment. Search the code base. The project also contains hundreds of calls to this routine; one can see what others did.
In my youth I coauthored a computer algebra system, but my contributions were all core code, inner loops, not close to the user interface. Yet many people managed to hack our system successfully. I had no meaningful advantage over them when I needed to do this myself, but their example spurred me to learn.
Same with flunking my quals, first semester of my PhD program. The older students would tear through the questions in five minutes, at tea after each miserable day of testing. With this experience in mind, I doubled my scores the next semester.
One really has to just dive into the code, and others do this.
Title ahould contain "(2015)" - you'll see the "2015-01-07" date at the bottom.
The original Atreus was programmed with Microscheme, but it has not been that way for a few years at least. TMK was the recommended firmware when I started using one in 2016. Currently you'll see QMK as the defacto. That will likely change this year after the Atreus 2 is released. The kickstarter campaign for it launched one week ago.
Scheme still is used in the project, just not for firmware. The git repo has a scheme program in it to generate a PCB for an Atreus provided one specifies the desired number of rows, number of columns, angle, and column-stagger.
Geez, I feel like by the time you're releasing utilities named "Menelaus" for your product named "Atreus", you kind of need to address the question "why is your product named after a guy whose only notable feature was that all of his descendants experienced ruin and death?"
That's a good point, but it ignores two other notable descendants: Orestes (who is legendary for establishing the precursor to the modern judicial system and who I named my firmware written in Forth after http://github.com/technomancy/orestes) and Paul Atreides, who as you may know was Muad'Dib and was capable of seeing the flow of cause and effect unfold across spacetime.
That article goes into more background but it's based on a much earlier version of the firmware; as of last week I've gotten it to be feature-complete and stable, and I've been using it as my daily driver.
I have been meaning to follow up the article with a part 3 that covers the rest of the features, but in the mean time I have added copious comments to the source link above such that it covers almost everything you need to know. (This is probably the most heavily-commented piece of code I've ever written with a 1:1 code:comments ratio.)
If you've looked at building an Atreus before but gotten intimidated by the soldering, we have a kickstarter for a non-DIY version that's significantly cheaper than the kit: https://www.kickstarter.com/projects/keyboardio/atreus
Thanks; the title is fine. The current link is probably a better starting point; I've added links to the most recent revision so folks can see the final product if they want.
That said, tweaking the behavior of tap/hold dual function keys is voodoo. There are a few flags one can set, or one can replace the keystroke inner loop, which I'm about to do. 18 of my 30 core alpha keys are dual function, either modifiers or access to other layers. I have many shortcuts that involve one finger from each hand in sequence, easy chording. However, change keyboards and I trip over myself on fast ordinary typing, accidentally triggering sequences that rearrange the orbits of the planets. (I used to use Emacs, so I'm used to this.)
Everyone types differently, so "this works for me" rarely helps. Every mechanical switch activates differently, so one can adapt to one keyboard and be back at ground zero on another keyboard.
Scheme would be great for creating a DSL implementing arbitrary flow charts for the state transitions as keypresses register down or up, and timers fire. Writing this in C is tedious. And if chording ever "just worked" many more people would adopt it.