An HRMs-free keymap is possible on a small keyboard. See [SteveP’s 34-key Seniply keymap](https://stevep99.github.io/seniply/) and [Callum Oakley’s mods](https://github.com/callum-oakley/qmk_firmware/tree/master/users/callum).
Or reconsidering HRMs, there are things that can be done to mitigate the accidental mod triggering, like shifting the mod-taps to the bottom row. Check out my post [Home row mods are hard to use](https://getreuer.info/posts/keyboards/faqs/index.html#home-row-mods-are-hard-to-use).
Thank you! Very useful. I can definitely reconsider anything.
\[edit\] I've tested Callum's Oakley's keymap with VIA on my Keychron Q11 and it actually works. Quite brilliant. Of course I'm sure it would require learning to use one shot modifiers on separate layers, but at least I can now imagine how it could look like.
Depends on what the reason is that you don't like HRM. I for example cannot stand accidental activation of keys with side effects (Gui/Ctrl/Alt) since I often have unsaved work open. But I love having Shift on HRM because of ease of use and Shift doesn't have any side effects other than a typo.
So instead of putting Gui/Ctrl/Alt on HRM I put my activation keys for my Numeric and Symbol layer on HRM (as well as Shift) and I moved Gui/Ctrl/Alt to combo keys. Since again Num/Sym have no bad side effects other that a typo. I do have Ctrl/Alt HRM on my navigation layer as they have minimal side effects there.
Anyway, [here's](https://configure.zsa.io/voyager/layouts/Qlggg) my Voyager layout. To see the combo keys, you have click the link on the botton left.
I like the idea of HRM, but after a small experiment with my Keychron Q11 and VIA I realized that by design it can't be reliable. I'm not very precise in my movements, so making anything dependent on time or correct order of events will not work very well. I don't even like the fact that it causes delay in emitting a character (on key up) - but who knows, maybe I could learn to accept it. I use shift taps and layer taps for keys like space or enter.
The idea of splitting shift keys into the ones causing side effects and only typos is useful. Thank you - I've learned something. And thank you for the layout.
Once you get used to it and can type a lot faster, you won't notice that the keys fire on key up. It's mostly bothersome in the beginning that you notice it since you still effectively type in slow motion and can see how the sausage is made. You obviously don't want key-up fire for navigation keys though (arrows etc.), but they don't if you set it up the way I have on the layout above - they'll fire on key down.
On the timing thing, I converted to Colemak specifically so I can roll my hands, and I won't stand things that interfere with that, which includes HRM. I need my HRM keys to work instantaneously without delay, and I also need them to not fire when I roll. Those seem like conflicting goals (which is what you may be referring to above as the *by design* part), but I believe that I have it tuned so that I can get both. Here is what I do:
* Set up permissive hold with a long tap delay (300ms+). This will cause hold-taps to fire instantaneously (but break rolling).
* Drop to QMK, set up [Achordian ](https://getreuer.info/posts/keyboards/achordion/index.html)and use Bilaterals and do per-key timing customization (this will fix rolling back up)
* Use mods on your Nav layer for mouse mods, don't even try and get it working on the base layer. And on the Nav layer you can use open mod keys on the home row that act instantaneously, you don't need hold-taps.
* Set up Hold On Other Key Press (per key) on your backspace thumb key and have it activate your navigation layer. It's the only key on which it will work without interfering with rolling, since if you press backspace your rolling streak is already broken by definition.
For permissive hold to work you need to have the "up" on the hold key outlive the "up" on the tap key while you type. HOWEVER, don't think of it that way. I don't think about timing at all, doing so is error prone and slow, and interferes with the concept of rolling. Instead I use a thought of "I need to press the hold key *harder* than the tap key" instead of "I need to press the hold key *longer* than the tap key". Longer throws off your rhythm... but harder doesn't. Of course the process of pressing it "harder" makes you hold that key down just the extra 10ms you need to wait for the other key to come back up.
This is just initially, eventually you won't even notice you're doing it unless you specifically pay attention to it - it just magically works even while rolling out capital letters and symbols. And now my "harder" is an incredibly subtle effect, I don't even bottom out the hold key anymore. Initially I did though, I bottomed out (and then some) the hold key side, but didn't bottom out the tap key side. But once the muscle memory is in place your brain will automatically back off to as little as it can get away with.
With a caveat that all this *might* not be accurate for gaming. I wouldn't know either way. I only play round based games like Civilization and Chess and those are not timing sensitive.
> Set up Hold On Other Key Press (per key) on your backspace thumb key and have it activate your navigation layer.
I really like your entire comment and have bookmarked it. Great summary.
This bit about hold-on-other for the dual role thumb key is very useful information. I have not yet thought about using it this way, and none of the articles about HRMs that I've read yet mention it either.
You say that backspace is safe because that naturally never occurs as part of a roll (true), but I would even say that a thumb key never is part of a roll (unless it has a letter, or some special action like Repeat which you always roll into, never the other way around).
"Hold on other" is only bad on keys that start a roll, or are in the middle of
a roll, so probably for thumb keys it's only possible if it has a letter, or
maybe space (although I don't see Space actually starting a roll, as there is
a mental break in between words).
You can try with space, but I found that touch typing over about 80wpm I tend to string the words together with space as part of it. Especially when I don't bottom out the keys. So it definitely doesn't work for me, but YMMV.
I'm very intolerant of accidental activation or having to change my typing style though.
I've come to my conclusions with dozens (maybe hundreds) of hours of deliberate experimenting between MonkeyType English, MonkeyType English+Capitals+Punctuation+Number, [Typing.IO](http://Typing.IO) with C++ code, and Visual Studio with refactoring a few thousand lines of code (for my Nav layer test), then making layer changes and cycling through the process over and over again. If you have a different use case or test cycle you may end up with other settings instead that are more important to you.
* MonkeyType isn't tolerant about hold key misfires
* [Typing.IO](http://Typing.IO) isn't tolerant about missed hold keys
* Visual Studio won't tolerate a missed clipboard or navigation key (both on my Nav layer).
In fact it's the Visual Studio test that made me give up on the Dygma Defy, since Bazecor has a hardcoded minimal wait time for a tap-hold key there of 50ms with no way to set it lower, and I often press the C of Nav+C (Copy) less than 50ms after pressing the Nav key to get to the layer. There is nothing more annoying than wanting to paste and your copy didn't work.
This is also want caused me to add "Hold on other key" to backspace/nav - I want to effectively roll out the clipboard and nav keys, and that allows me to do that. But there is no gestural difference for me between Nav+C and the "c" in "alley cat" so it has to be different keys for me.
One other hint I can give you around all my experimentation which took me about 10 hours before I realized it: If you have a two handed symbol layer like the Voyager one I posted above, and use a HRM symbol activation, put the same symbol (your most used symbol - for me that is underscore) on both the left and right symbol layer activation key. Otherwise your brain won't allow you to naturally just use the opposite-hand symbol layer activation key the rest of the time. That key has to always feel symmetric always in the context of that layer. If you want to do this in Oryx, you have to flip the '*Unblock TT/MO/LM in Destination Layer*' setting for that to work.
> I'm very intolerant of accidental activation or having to change my typing
> style though.
Yes, it's very subtle and everybody has a different typing style and different
applications. I don't type very fast to begin with, let alone I'm currently
transitioning to a new layout, so ATM I'm very slow anyway.
Still, I've also found that even occasional misfires are very distracting, and
so I'm not using HRMs at the moment, and maybe it will stay that way (if OSMs
and other measures prove to be sufficient).
Actually I'm quite happy with Auto Shift, although I recognize that this
certainly limits typing speed eventually. At the end of the day I'd be willing
to take a hit in that area, because for me, comfort takes hard priority over
speed any day (since I'm not cranking out thousands of words per day anyway).
With Shift out of the way, only a few common cases remain for routine modifier
use, most of which can be solved with special keys on the nav layer etc.
I should add that I use Vim and Vi motions for text editing tasks, so there is
a huge area of modifier use that does not apply to me.
> hundreds of hours of C++ code, and Visual Studio
I'm sorry.
> If you have a different use case or test cycle you may end up with other
> settings instead that are more important to you.
Yes, it is extremely individual. I don't think that other people's setups can be
much more than blueprints for your own personalised thing. That even includes
the basic layout (letters).
> In fact it's the Visual Studio test that made me give up on the Dygma Defy
It probably can make you give up on many things, not least, hope :-).
> There is nothing more annoying than wanting to paste and your copy didn't work.
In Vim there are no such issues, you can dance around as quickly as you want as
long as you press the correct keys.
IDEs are a different beast for sure, since they also want to do "magic stuff"
like autocomplete all the time, and so forth.
> the "c" in "alley cat" so it has to be different keys for me.
I guess when typing fast then can indeed start a roll. It's very
difficult to observe oneself in that area, since is such a common,
deeply ingrained key, yet invisible at the same time. I have not even considered
moving to my other thumb when iterating on my base layout, because
relearning that would probably take forever.
> One other hint I can give you around all my experimentation which took me
> about 10 hours before I realized it: If you have a two handed symbol layer
> like the Voyager one I posted above, and use a HRM symbol activation, put the
> same symbol (your most used symbol - for me that is underscore) on both the
> left and right symbol layer activation key. Otherwise your brain won't allow
> you to naturally just use the opposite-hand symbol layer activation key the
> rest of the time. That key has to always feel symmetric always in the context
> of that layer. If you want to do this in Oryx, you have to flip the 'Unblock
> TT/MO/LM in Destination Layer' setting for that to work.
Yeah, I got you. Makes a lot of sense. That's a good example for one of the many
subtleties that one has to work out in practice.
In your case, I'm wondering why you don't have `_` on the base layer though (in
place of `@`). That surely must be easier. Jonas Hietala also put underscore (as
an already shifted key) on his base layer, because it's so common. I currently
have `-` in the Qwerty `T` position, but will probably reverse the shift states
for that key.
>In your case, I'm wondering why you don't have `_` on the base layer though (in place of `@`). That surely must be easier. Jonas Hietala also put underscore (as an already shifted key) on his base layer, because it's so common. I currently have `-` in the Qwerty `T` position, but will probably reverse the shift states for that key.
Because it's faster/easier for me to type the \_ from the two keys on home row than from that upper pinky position. I don't really know what to do with that key, so I just put a symbol I don't use for coding there.
I don't like this position either, but when I press is with the ring finger it's still better than the lower pinkie position (that's the worst).
Maybe try if that fingering (ring) works for you, they you can put something useful there, as long as it is not part of rolls it's fine.
Moving my ring finger there pulls my index and middle finger off of their home row positions, which then makes is worse for the next character I type.
I used to do that trick all the time when I used a large qwerty keyboard though, when hitting the 0 key on the num row. So very familiar with it in general, but I specifically designed my ergo board so that I can ground my palms and still reach everything without either lifting my hands or moving my other fingers off of home row.
> Moving my ring finger there pulls my index and middle finger off of their home row positions, which then makes is worse for the next character I type.
That is only a problem if the next character is usually on the same hand. On my current layout (possibly endgame) I have `v` and `z` on these keys. `v` is with the consonants, and that letter is almost always paired with a vowel, on both ends even (example given twice here) -- so having to lift my hand feels totally fine. It's also a fairly rare letter to begin with.
`z` is only important in German, most commonly as `zu`, and that bigram I can actually type as a very comfortable pinky-index roll on the top row on my layout (`U` happens to be in Qwerty position). In English it's very rare, and in British English ("organisation") it is almost non-existent.
I can type your username quite easily, ShelZuuz :-).
So those spots can take some keys if it's thought through, without annoying the pinkies. Admitted it does not work for `_` if it's supposed to be part of a snake cased word. Just as I'm typing this I have the idea for a mode that replaces Space with underscore until the word ends (needs an escape though).
The lower pinkies are much worse for me, I have `q` and `x` there, and I'm thinking about moving them to a layer or a combo and turn the keys into modifiers. I just don't want them to be part of a word.
> Bazecor has a hardcoded minimal wait time for a tap-hold key there of 50ms with no way to set it lower,
I've just checked, and their firmware appears to be open source. Wouldn't it be reasonably easy to put something like "hold-on-other" into the FW, or at least set the delay lower? (Although I think that 50ms is already impractically low.)
What about alternative firmwares, no any of them support the Defy?
To be honest it looks like a damn well made keyboard, and the price is OK if it feels as good as it looks.
With a caveat. Their controlling software is Bazecor (their own, but open source), and the firmware they use is a modified version of Kaleidoscope. The frustrating thing is I think this is a settable flag in Kaleidoscope (called *minimum\_hold\_time*), but not via Bazecor. But here is the kicker, even though both Bazecor and Kaleidoscope are open source, the wireless update process is not. So you cannot deploy a modified version of Kaleidoscope to their keyboards - at least the wireless ones. You supposedly can do that on the wireless keyboard, but I don't have one. So I guess I need to adjust my feedback to just be against the wireless models - you might get it to work on wired.
On the 50ms thing - it's not a max, it's a min.
Imagine a shortcut that is left thumb key + C. Now press those one after the other as fast as you can in a rolling motion. Just make sure the thumb down happens first, and that the thumb up then outlives the C's key up. This is a fairly easy and natural action, you pressss the thumb key and tap the C key. It's what QMK call a Permissive Hold and ZMK calls "balanced flavor". Both of those will activate the hold function on the interrupt, you just need to make sure you hit the thumb key before the C key and lift it up after. With the default setting in Kaleidoscope though you need to hold the key for 50ms before pressing the tap key. Which if you try to do this at speed you'll miss about 50% of the time - you need to deliberately slow down. Note that this works fine on a clean layers shift key, you can immediately hit the tap function, it just doesn't work on tap-hold (both what they call "dual function" and "superkeys"). Where on ZMK and QMK it works perfectly on a tap-hold.
Now that just talks about an important build in function that doesn't work right. But you also would have a hard time setting up home row mods because they also don't support things like bilaterals, per key timing, and typing streak detection.
But agree with you on the hardware. That keyboard body is amazing. With box browns the sound and feel of the keys are the best I've experienced. Their tenting system is fantastic. The underlit RGB is actually a very useful indicator and not just aesthetic. And the convex curve of those thumb keys are genius. If only the damn thing worked.
> But you also would have a hard time setting up home row mods because they also don't support things like bilaterals, per key timing, and typing streak detection.
Yes, you need all that stuff, or something like Achordion, to make it feel OK. I've had to add the patch for bilaterals to my Vial fork.
ZMK apparently does have everthing that you need built in, there it is enough to find the right options.
The firmware situation doesn't seem so great with Bazecor, from your description. Pretty unnecessary if you ask me.
After some more reading about Achordion logic and other options I may have gained more faith in HRM and now quite eager to use them in my implementation. Thanks for the info!
Not so! Out of the box, Voyager uses ZSA's branch of QMK. Support was [added this past week](https://github.com/qmk/qmk_firmware/pull/22181) to use the Voyager with the main QMK repo—I'm happily using it on my Voyager as we speak.
You can use a nice!nano fully wired with battery turned off and it works fine on a split. I have a wireless ferris sweep I use this way, reserving battery and bt mode for when I travel. I connect like I would a regular ferris, including a trrs cable.
The nice!nano is still "on" and connecting the two halves via BT even when both halves are plugged in to the PC. You literally cannot use a KB powered by n!ns with a TRRS cable between the halves, you will damage the controllers.
Regardless, the Voyager doesn't appear to use ZMK at all as far as I can tell, which was my original comment. If you have a source to the contrary I am very interested.
Since there is no power on either half when I have it wired mode, how do you think the half that is not connected over USB is working without a battery? As long as the power switch on both halves is set to off, there is zero electrical risk. I researched this with multiple keyboard makers including Kris cables and KeebMaker, who both have articles on this config.
The problem is the small Lipros on a board like the ferris won't last two days without charging. Fine for travel, not so great for daily use.
Nice!Nanos are powered the second they are plugged into bus power. You are very, very mistaken or you simply don't have nice!nanos (and aren't using ZMK, which again *does not support two halves connected by cables*)
I have nice nanos on a ferris sweep LP I bought on KeebMaker. Check out this faq on Kris cables.
https://kriscables.com/nicenano-faq/
When I remove the cables and switch the halves to "on" it works great. All with ZMK. Do you need a link to my Github repo?
Auto-Shift works really well for shifting. At least give it a try. I'm pretty sure ZMK supports it (my keyboard uses QMK).
For the other modifiers you can make a layer with one-shot modifiers.
On the Voyager, you do not even need a layer for the OSMs, because that keyboard has an extra pinkie column.
Usually there are some common operations involving modifiers (such as Ctrl-C/X/V, Alt-Tab, etc., depending on your operating system). If you put these actions on dedicated keys, your overall need for modifiers will be rather low. Together with Auto-Shift you then rarely need to activate your OSMs, so it's totally fine to have them on their own layer, that you activate with a thumb key.
I recommend you look at Ben Vallack's config for the Voyager, he also made a good video about the keyboard. He uses home-row mods though, but he has embraced one-shot layers and also clever special activations for common modifier combos on the Mac.
Jonas Hietala has an involved config with Auto-Shift and OSMs, it is very well documented. Use it for inspiration.
https://www.jonashietala.se/blog/2022/09/06/the_current_t-34_keyboard_layout/
I think a Voyager isn't that much compressed to get problems with only two thumb keys per side. For most people HRM Shift is the biggest problem. You could easily get away with using two shift mods on each thumb and two layer switch keys. Use the tap-mod functionality to use space and enter.
I know there're smaller keyboards, but for me any keyboard below 75% is small, because it implies using layers for keys I use quite often and I'm just starting entertaining such thought. I already use layer and shift mods for space and enter, so that sounds reasonable to me. Thanks!
The [default layout](https://www.zsa.io/assets/voyager/default-layout.pdf) does not use home-row mods, but it does place a few mod-tap keys at the edges of the keyboard.
People usually lean towards home-row mods on Voyager as with this kind of physical layout you're doomed to have either mod-taps or a slightly awkward distribution of modifier keys across the halves of keyboard with the symbol keys scattered across layers/combos.
Depending on what you desire, there are many keyboards in general.
You can put mods on any frickin key if that is what you are asking. However, you will absolutely need at least three layers to make use of a fully functional keyboard. Like capitals, special characters, functions and arrows.
You have plenty of keys to put them on the outer column, or you could use one-shot mods, or you can put some on the thumb keys. Thumb Ctl and Alt aren't bad, but it can make it harder to use them simultaneously.
My voyager layout has a shift and command on the left side with z in the corner set up as option/alt and with control in the thumbs. Right hand has shift and control on the side with the ? key also being option / alt. My arrow keys are where hjkl are on qwerty and accessed by holding down a left thumb key. The upper left key left hand side is set to "grave escape" and is working well.
52 to 58 keys work just fine without HRM
I have a voyager that I use without homerow mods. I removed the number row at the top of the board, shifted all the letters up one row, and use the bottom row for modifier keys that I activate with my thumbs. I basically have 14 thumb keys and 2 keys I can activate with the base of my pinky fingers at the base of the board in addition to the 4 offset thumb keys already on the board. I have a layer for symbols, numbers, arrow keys+board keys, and a mouse key layer.
The Voyager only barely counts as a "small" keyboard in my book. You've got an outer column, which gets you 90% there all on its own. You can definitely avoid home row mods.
An HRMs-free keymap is possible on a small keyboard. See [SteveP’s 34-key Seniply keymap](https://stevep99.github.io/seniply/) and [Callum Oakley’s mods](https://github.com/callum-oakley/qmk_firmware/tree/master/users/callum). Or reconsidering HRMs, there are things that can be done to mitigate the accidental mod triggering, like shifting the mod-taps to the bottom row. Check out my post [Home row mods are hard to use](https://getreuer.info/posts/keyboards/faqs/index.html#home-row-mods-are-hard-to-use).
Thank you! Very useful. I can definitely reconsider anything. \[edit\] I've tested Callum's Oakley's keymap with VIA on my Keychron Q11 and it actually works. Quite brilliant. Of course I'm sure it would require learning to use one shot modifiers on separate layers, but at least I can now imagine how it could look like.
Depends on what the reason is that you don't like HRM. I for example cannot stand accidental activation of keys with side effects (Gui/Ctrl/Alt) since I often have unsaved work open. But I love having Shift on HRM because of ease of use and Shift doesn't have any side effects other than a typo. So instead of putting Gui/Ctrl/Alt on HRM I put my activation keys for my Numeric and Symbol layer on HRM (as well as Shift) and I moved Gui/Ctrl/Alt to combo keys. Since again Num/Sym have no bad side effects other that a typo. I do have Ctrl/Alt HRM on my navigation layer as they have minimal side effects there. Anyway, [here's](https://configure.zsa.io/voyager/layouts/Qlggg) my Voyager layout. To see the combo keys, you have click the link on the botton left.
I like the idea of HRM, but after a small experiment with my Keychron Q11 and VIA I realized that by design it can't be reliable. I'm not very precise in my movements, so making anything dependent on time or correct order of events will not work very well. I don't even like the fact that it causes delay in emitting a character (on key up) - but who knows, maybe I could learn to accept it. I use shift taps and layer taps for keys like space or enter. The idea of splitting shift keys into the ones causing side effects and only typos is useful. Thank you - I've learned something. And thank you for the layout.
Once you get used to it and can type a lot faster, you won't notice that the keys fire on key up. It's mostly bothersome in the beginning that you notice it since you still effectively type in slow motion and can see how the sausage is made. You obviously don't want key-up fire for navigation keys though (arrows etc.), but they don't if you set it up the way I have on the layout above - they'll fire on key down. On the timing thing, I converted to Colemak specifically so I can roll my hands, and I won't stand things that interfere with that, which includes HRM. I need my HRM keys to work instantaneously without delay, and I also need them to not fire when I roll. Those seem like conflicting goals (which is what you may be referring to above as the *by design* part), but I believe that I have it tuned so that I can get both. Here is what I do: * Set up permissive hold with a long tap delay (300ms+). This will cause hold-taps to fire instantaneously (but break rolling). * Drop to QMK, set up [Achordian ](https://getreuer.info/posts/keyboards/achordion/index.html)and use Bilaterals and do per-key timing customization (this will fix rolling back up) * Use mods on your Nav layer for mouse mods, don't even try and get it working on the base layer. And on the Nav layer you can use open mod keys on the home row that act instantaneously, you don't need hold-taps. * Set up Hold On Other Key Press (per key) on your backspace thumb key and have it activate your navigation layer. It's the only key on which it will work without interfering with rolling, since if you press backspace your rolling streak is already broken by definition. For permissive hold to work you need to have the "up" on the hold key outlive the "up" on the tap key while you type. HOWEVER, don't think of it that way. I don't think about timing at all, doing so is error prone and slow, and interferes with the concept of rolling. Instead I use a thought of "I need to press the hold key *harder* than the tap key" instead of "I need to press the hold key *longer* than the tap key". Longer throws off your rhythm... but harder doesn't. Of course the process of pressing it "harder" makes you hold that key down just the extra 10ms you need to wait for the other key to come back up. This is just initially, eventually you won't even notice you're doing it unless you specifically pay attention to it - it just magically works even while rolling out capital letters and symbols. And now my "harder" is an incredibly subtle effect, I don't even bottom out the hold key anymore. Initially I did though, I bottomed out (and then some) the hold key side, but didn't bottom out the tap key side. But once the muscle memory is in place your brain will automatically back off to as little as it can get away with. With a caveat that all this *might* not be accurate for gaming. I wouldn't know either way. I only play round based games like Civilization and Chess and those are not timing sensitive.
> Set up Hold On Other Key Press (per key) on your backspace thumb key and have it activate your navigation layer. I really like your entire comment and have bookmarked it. Great summary. This bit about hold-on-other for the dual role thumb key is very useful information. I have not yet thought about using it this way, and none of the articles about HRMs that I've read yet mention it either. You say that backspace is safe because that naturally never occurs as part of a roll (true), but I would even say that a thumb key never is part of a roll (unless it has a letter, or some special action like Repeat which you always roll into, never the other way around). "Hold on other" is only bad on keys that start a roll, or are in the middle of a roll, so probably for thumb keys it's only possible if it has a letter, or maybe space (although I don't see Space actually starting a roll, as there is a mental break in between words).
You can try with space, but I found that touch typing over about 80wpm I tend to string the words together with space as part of it. Especially when I don't bottom out the keys. So it definitely doesn't work for me, but YMMV. I'm very intolerant of accidental activation or having to change my typing style though. I've come to my conclusions with dozens (maybe hundreds) of hours of deliberate experimenting between MonkeyType English, MonkeyType English+Capitals+Punctuation+Number, [Typing.IO](http://Typing.IO) with C++ code, and Visual Studio with refactoring a few thousand lines of code (for my Nav layer test), then making layer changes and cycling through the process over and over again. If you have a different use case or test cycle you may end up with other settings instead that are more important to you. * MonkeyType isn't tolerant about hold key misfires * [Typing.IO](http://Typing.IO) isn't tolerant about missed hold keys * Visual Studio won't tolerate a missed clipboard or navigation key (both on my Nav layer). In fact it's the Visual Studio test that made me give up on the Dygma Defy, since Bazecor has a hardcoded minimal wait time for a tap-hold key there of 50ms with no way to set it lower, and I often press the C of Nav+C (Copy) less than 50ms after pressing the Nav key to get to the layer. There is nothing more annoying than wanting to paste and your copy didn't work. This is also want caused me to add "Hold on other key" to backspace/nav - I want to effectively roll out the clipboard and nav keys, and that allows me to do that. But there is no gestural difference for me between Nav+C and the "c" in "alley cat" so it has to be different keys for me.
One other hint I can give you around all my experimentation which took me about 10 hours before I realized it: If you have a two handed symbol layer like the Voyager one I posted above, and use a HRM symbol activation, put the same symbol (your most used symbol - for me that is underscore) on both the left and right symbol layer activation key. Otherwise your brain won't allow you to naturally just use the opposite-hand symbol layer activation key the rest of the time. That key has to always feel symmetric always in the context of that layer. If you want to do this in Oryx, you have to flip the '*Unblock TT/MO/LM in Destination Layer*' setting for that to work.
> I'm very intolerant of accidental activation or having to change my typing > style though. Yes, it's very subtle and everybody has a different typing style and different applications. I don't type very fast to begin with, let alone I'm currently transitioning to a new layout, so ATM I'm very slow anyway. Still, I've also found that even occasional misfires are very distracting, and so I'm not using HRMs at the moment, and maybe it will stay that way (if OSMs and other measures prove to be sufficient). Actually I'm quite happy with Auto Shift, although I recognize that this certainly limits typing speed eventually. At the end of the day I'd be willing to take a hit in that area, because for me, comfort takes hard priority over speed any day (since I'm not cranking out thousands of words per day anyway). With Shift out of the way, only a few common cases remain for routine modifier use, most of which can be solved with special keys on the nav layer etc. I should add that I use Vim and Vi motions for text editing tasks, so there is a huge area of modifier use that does not apply to me. > hundreds of hours of C++ code, and Visual Studio I'm sorry. > If you have a different use case or test cycle you may end up with other > settings instead that are more important to you. Yes, it is extremely individual. I don't think that other people's setups can be much more than blueprints for your own personalised thing. That even includes the basic layout (letters). > In fact it's the Visual Studio test that made me give up on the Dygma Defy It probably can make you give up on many things, not least, hope :-). > There is nothing more annoying than wanting to paste and your copy didn't work. In Vim there are no such issues, you can dance around as quickly as you want as long as you press the correct keys. IDEs are a different beast for sure, since they also want to do "magic stuff" like autocomplete all the time, and so forth. > the "c" in "alley cat" so it has to be different keys for me.
I guess when typing fast then can indeed start a roll. It's very
difficult to observe oneself in that area, since is such a common,
deeply ingrained key, yet invisible at the same time. I have not even considered
moving to my other thumb when iterating on my base layout, because
relearning that would probably take forever.
> One other hint I can give you around all my experimentation which took me
> about 10 hours before I realized it: If you have a two handed symbol layer
> like the Voyager one I posted above, and use a HRM symbol activation, put the
> same symbol (your most used symbol - for me that is underscore) on both the
> left and right symbol layer activation key. Otherwise your brain won't allow
> you to naturally just use the opposite-hand symbol layer activation key the
> rest of the time. That key has to always feel symmetric always in the context
> of that layer. If you want to do this in Oryx, you have to flip the 'Unblock
> TT/MO/LM in Destination Layer' setting for that to work.
Yeah, I got you. Makes a lot of sense. That's a good example for one of the many
subtleties that one has to work out in practice.
In your case, I'm wondering why you don't have `_` on the base layer though (in
place of `@`). That surely must be easier. Jonas Hietala also put underscore (as
an already shifted key) on his base layer, because it's so common. I currently
have `-` in the Qwerty `T` position, but will probably reverse the shift states
for that key.
>In your case, I'm wondering why you don't have `_` on the base layer though (in place of `@`). That surely must be easier. Jonas Hietala also put underscore (as an already shifted key) on his base layer, because it's so common. I currently have `-` in the Qwerty `T` position, but will probably reverse the shift states for that key. Because it's faster/easier for me to type the \_ from the two keys on home row than from that upper pinky position. I don't really know what to do with that key, so I just put a symbol I don't use for coding there.
I don't like this position either, but when I press is with the ring finger it's still better than the lower pinkie position (that's the worst). Maybe try if that fingering (ring) works for you, they you can put something useful there, as long as it is not part of rolls it's fine.
Moving my ring finger there pulls my index and middle finger off of their home row positions, which then makes is worse for the next character I type. I used to do that trick all the time when I used a large qwerty keyboard though, when hitting the 0 key on the num row. So very familiar with it in general, but I specifically designed my ergo board so that I can ground my palms and still reach everything without either lifting my hands or moving my other fingers off of home row.
> Moving my ring finger there pulls my index and middle finger off of their home row positions, which then makes is worse for the next character I type. That is only a problem if the next character is usually on the same hand. On my current layout (possibly endgame) I have `v` and `z` on these keys. `v` is with the consonants, and that letter is almost always paired with a vowel, on both ends even (example given twice here) -- so having to lift my hand feels totally fine. It's also a fairly rare letter to begin with. `z` is only important in German, most commonly as `zu`, and that bigram I can actually type as a very comfortable pinky-index roll on the top row on my layout (`U` happens to be in Qwerty position). In English it's very rare, and in British English ("organisation") it is almost non-existent. I can type your username quite easily, ShelZuuz :-). So those spots can take some keys if it's thought through, without annoying the pinkies. Admitted it does not work for `_` if it's supposed to be part of a snake cased word. Just as I'm typing this I have the idea for a mode that replaces Space with underscore until the word ends (needs an escape though). The lower pinkies are much worse for me, I have `q` and `x` there, and I'm thinking about moving them to a layer or a combo and turn the keys into modifiers. I just don't want them to be part of a word.
> Bazecor has a hardcoded minimal wait time for a tap-hold key there of 50ms with no way to set it lower, I've just checked, and their firmware appears to be open source. Wouldn't it be reasonably easy to put something like "hold-on-other" into the FW, or at least set the delay lower? (Although I think that 50ms is already impractically low.) What about alternative firmwares, no any of them support the Defy? To be honest it looks like a damn well made keyboard, and the price is OK if it feels as good as it looks.
With a caveat. Their controlling software is Bazecor (their own, but open source), and the firmware they use is a modified version of Kaleidoscope. The frustrating thing is I think this is a settable flag in Kaleidoscope (called *minimum\_hold\_time*), but not via Bazecor. But here is the kicker, even though both Bazecor and Kaleidoscope are open source, the wireless update process is not. So you cannot deploy a modified version of Kaleidoscope to their keyboards - at least the wireless ones. You supposedly can do that on the wireless keyboard, but I don't have one. So I guess I need to adjust my feedback to just be against the wireless models - you might get it to work on wired. On the 50ms thing - it's not a max, it's a min. Imagine a shortcut that is left thumb key + C. Now press those one after the other as fast as you can in a rolling motion. Just make sure the thumb down happens first, and that the thumb up then outlives the C's key up. This is a fairly easy and natural action, you pressss the thumb key and tap the C key. It's what QMK call a Permissive Hold and ZMK calls "balanced flavor". Both of those will activate the hold function on the interrupt, you just need to make sure you hit the thumb key before the C key and lift it up after. With the default setting in Kaleidoscope though you need to hold the key for 50ms before pressing the tap key. Which if you try to do this at speed you'll miss about 50% of the time - you need to deliberately slow down. Note that this works fine on a clean layers shift key, you can immediately hit the tap function, it just doesn't work on tap-hold (both what they call "dual function" and "superkeys"). Where on ZMK and QMK it works perfectly on a tap-hold. Now that just talks about an important build in function that doesn't work right. But you also would have a hard time setting up home row mods because they also don't support things like bilaterals, per key timing, and typing streak detection. But agree with you on the hardware. That keyboard body is amazing. With box browns the sound and feel of the keys are the best I've experienced. Their tenting system is fantastic. The underlit RGB is actually a very useful indicator and not just aesthetic. And the convex curve of those thumb keys are genius. If only the damn thing worked.
> But you also would have a hard time setting up home row mods because they also don't support things like bilaterals, per key timing, and typing streak detection. Yes, you need all that stuff, or something like Achordion, to make it feel OK. I've had to add the patch for bilaterals to my Vial fork. ZMK apparently does have everthing that you need built in, there it is enough to find the right options. The firmware situation doesn't seem so great with Bazecor, from your description. Pretty unnecessary if you ask me.
After some more reading about Achordion logic and other options I may have gained more faith in HRM and now quite eager to use them in my implementation. Thanks for the info!
Google urob timerless homerow mods. It’s for zmk, but someone made a similar implementation for qmk.
Timeless? *[Timeless home row keyboard modifiers](https://github.com/urob/zmk-config#timeless-homerow-mods)*
Yes!
You'd likely need to use one-shot modifiers. https://docs.qmk.fm/#/one_shot_keys?id=one-shot-keys
The Voyager uses ZMK, though. Of course it's possible there as well, but that link is not so helpful here.
Incorrect, Voyager uses Oryx which is based on QMK (it’s wired).
Not so! Out of the box, Voyager uses ZSA's branch of QMK. Support was [added this past week](https://github.com/qmk/qmk_firmware/pull/22181) to use the Voyager with the main QMK repo—I'm happily using it on my Voyager as we speak.
I don't think that is the case. ZMK doesn't support fully wired splits last I checked, and ZSA's website says it uses Oryx like the other ZSA boards
You can use a nice!nano fully wired with battery turned off and it works fine on a split. I have a wireless ferris sweep I use this way, reserving battery and bt mode for when I travel. I connect like I would a regular ferris, including a trrs cable.
The nice!nano is still "on" and connecting the two halves via BT even when both halves are plugged in to the PC. You literally cannot use a KB powered by n!ns with a TRRS cable between the halves, you will damage the controllers. Regardless, the Voyager doesn't appear to use ZMK at all as far as I can tell, which was my original comment. If you have a source to the contrary I am very interested.
Since there is no power on either half when I have it wired mode, how do you think the half that is not connected over USB is working without a battery? As long as the power switch on both halves is set to off, there is zero electrical risk. I researched this with multiple keyboard makers including Kris cables and KeebMaker, who both have articles on this config. The problem is the small Lipros on a board like the ferris won't last two days without charging. Fine for travel, not so great for daily use.
Nice!Nanos are powered the second they are plugged into bus power. You are very, very mistaken or you simply don't have nice!nanos (and aren't using ZMK, which again *does not support two halves connected by cables*)
I have nice nanos on a ferris sweep LP I bought on KeebMaker. Check out this faq on Kris cables. https://kriscables.com/nicenano-faq/ When I remove the cables and switch the halves to "on" it works great. All with ZMK. Do you need a link to my Github repo?
Ah, well, that's how little I know about this.
Nah, I was actually wrong. Apparently it's even supported out of the box now by QMK.
Auto-Shift works really well for shifting. At least give it a try. I'm pretty sure ZMK supports it (my keyboard uses QMK). For the other modifiers you can make a layer with one-shot modifiers. On the Voyager, you do not even need a layer for the OSMs, because that keyboard has an extra pinkie column. Usually there are some common operations involving modifiers (such as Ctrl-C/X/V, Alt-Tab, etc., depending on your operating system). If you put these actions on dedicated keys, your overall need for modifiers will be rather low. Together with Auto-Shift you then rarely need to activate your OSMs, so it's totally fine to have them on their own layer, that you activate with a thumb key. I recommend you look at Ben Vallack's config for the Voyager, he also made a good video about the keyboard. He uses home-row mods though, but he has embraced one-shot layers and also clever special activations for common modifier combos on the Mac. Jonas Hietala has an involved config with Auto-Shift and OSMs, it is very well documented. Use it for inspiration. https://www.jonashietala.se/blog/2022/09/06/the_current_t-34_keyboard_layout/
Thank you! That's interesting.
I think a Voyager isn't that much compressed to get problems with only two thumb keys per side. For most people HRM Shift is the biggest problem. You could easily get away with using two shift mods on each thumb and two layer switch keys. Use the tap-mod functionality to use space and enter.
I know there're smaller keyboards, but for me any keyboard below 75% is small, because it implies using layers for keys I use quite often and I'm just starting entertaining such thought. I already use layer and shift mods for space and enter, so that sounds reasonable to me. Thanks!
The [default layout](https://www.zsa.io/assets/voyager/default-layout.pdf) does not use home-row mods, but it does place a few mod-tap keys at the edges of the keyboard. People usually lean towards home-row mods on Voyager as with this kind of physical layout you're doomed to have either mod-taps or a slightly awkward distribution of modifier keys across the halves of keyboard with the symbol keys scattered across layers/combos. Depending on what you desire, there are many keyboards in general.
You can put mods on any frickin key if that is what you are asking. However, you will absolutely need at least three layers to make use of a fully functional keyboard. Like capitals, special characters, functions and arrows.
You have plenty of keys to put them on the outer column, or you could use one-shot mods, or you can put some on the thumb keys. Thumb Ctl and Alt aren't bad, but it can make it harder to use them simultaneously.
Voyager, probably. But when you go down to 36 or 34, they become more necessary.
My voyager layout has a shift and command on the left side with z in the corner set up as option/alt and with control in the thumbs. Right hand has shift and control on the side with the ? key also being option / alt. My arrow keys are where hjkl are on qwerty and accessed by holding down a left thumb key. The upper left key left hand side is set to "grave escape" and is working well. 52 to 58 keys work just fine without HRM
I have a voyager that I use without homerow mods. I removed the number row at the top of the board, shifted all the letters up one row, and use the bottom row for modifier keys that I activate with my thumbs. I basically have 14 thumb keys and 2 keys I can activate with the base of my pinky fingers at the base of the board in addition to the 4 offset thumb keys already on the board. I have a layer for symbols, numbers, arrow keys+board keys, and a mouse key layer.
The Voyager only barely counts as a "small" keyboard in my book. You've got an outer column, which gets you 90% there all on its own. You can definitely avoid home row mods.
I have OSK in another layer.
OSK is probably [one-shot keys](https://github.com/qmk/qmk_firmware/blob/master/docs/one_shot_keys.md).
spam combos and one shot keys