At a first level, that’s 100% true.
For now, let’s plan to get them into the default sketch. I don’t think that hardcoding layouts will age well.
1 Like
Good point!!
Do I understand correctly that the DVORAK and COLEMARK layouts could be defined here:
and they will just be latent layers unless they are added to the enum here:
Or is it more complicated than that?
The “const Key keymaps[][ROWS][COLS] PROGMEM = {}” array is where they are defined.
The enum is just a way of getting nice names for the layers, rather than a list of
#define QWERTY 0
#define FUNCTION 1
#define NUMPAD 2
To get them into the list, we’re going to have to do something clever with #ifdefs
Or perhaps comment them out with instructions on how to enable them? Clever #ifdefs may make the code harder for beginners to read.
Or would it make sense to add separate sketches for Model01-Firmware_DVORAK.ino and Model01-Firmware.COLEMARK.ino to the Arduino package?
I’ll set this aside for now and keep writing. 
Are there instructions somewhere for removing and reinstalling keycaps? I don’t want to damage the keyboard by accident!
Well, the idea of clever ifdefs is that we end up with a nice, easy to understand pattern for disabling things that might have some advantages over commenting them out.
Separate sketches have the disadvantage that the content will start to skew over time.
We may be able to figure out some straightforward way to publish keymaps as libraries, so they’re easier to share and include.
3 Likes
I do the equivalent to DualUse on my Planck, an have been pleased with it, so I expect it to be a good idea on Model01.
I’ve just gotten a sketch built through the Arduino IDE and firmware installed using OneShot in prep for writing up the process, and I have a couple questions.
First, how hard is it to change the interval for double tapping a key? I’m too quick by default, and when I try to be deliberate about it I’m too slow.
Second, how hard would it be to do something obvious with the LED’s on the activating keys so that when they are double tapped on it’s obvious? I’m not sure it’s necessary to make an alteration for single taps, but accidentally triggering the FUNCTION layer to be persistent sort of puts the keyboard into Martian mode. Behavior akin to the NUMPAD layer would be nice.
Lastly, if I double tap R SHIFT and then single tap L SHIFT the function doesn’t release. I have to tap R SHIFT again. I assume this is the same for all the left/right pairs. Is that the desired behavior? The other questions are probably all feature requests, but this one feels accidental. At least I wouldn’t have done it that way, and it took me a little while to workout why it was happening, so if that is as designed I want to add a note about it to the docs.
And as a final note, this is so much kinder to my thumbs! Thanks again for this wonderful tool.
1 Like
There is no separate timeout for the double-tapping functionality, it uses the same timeout as one-shot itself (2.5 seconds by default). Changing that is as easy as putting OneShot.time_out = 1000; (substitute whatever value you wish, it’s in milliseconds) somewhere in the setup() method of your sketch, doesn’t matter where within that method. I usually put it after Kaleidoscope.use(), but that’s just habit.
I’m using the Colormap plugin for this purpose, which allows me to have a separate color theme for each layer, so if I accidentally double-tap, the theme changing will let me know clearly. Not quite the same solution you proposed, but achieves a similar thing.
Doing what you outlined would be… challenging to implement efficiently, without complicating OneShot even further.
I wouldn’t say it is desired, but I think this makes more sense than allowing the pair to toggle it off. My explanation for the double-tap toggle behaviour of OneShot is that double-tapping them simulates holding the key. On a normal keyboard, if you hold left shift, then tap and release right shift, the left will still remain active. That’s the same with OneShots.
I can add functionality that would allow the other pair to disable the toggle, but I wouldn’t make that the default behaviour, for reasons above, and because OneShots work this way on QMK too, and as far as I understand, with KLL as well. I think it help is we work similar to other implementations of the same functionality.
(I never noticed this being a problem, probably because I only have the left modifiers :))
2 Likes
Not sure I was clear with my question. when I double tap a key at the speed that is natural for me, the plugin is not going in to the “held down” mode reliably. I seem to need to slow down a little bit to make it work, but if I slow down too much it is also not registering as a double tap. I do have a light touch, so it could be my second click is just not registering mechanically sometimes.
That would work great for the FUNCTION layer, but since I also have CTRL, CMD, and SHIFT set up as OneShot’s, I can’t do anything to indicate that visually, since they are not activating layers.
I did just notice the Escape-OneShot plugin, and will be installing that as well, so I can just develop the habit of mashing ESC if my keyboard goes wonky. 
A modifier to enable the pairs to cancel each other would be nice, but is certainly not urgent. I expect it will be within my ability to create when I have the docs in a stable place, and can focus more on my personal goals.
Ah! My bad, you mentioned modifiers. Kaleidoscope-LED-ActiveModColor may be of interest to you then. With this, if you double-tap, the modifier key will glow white, and won’t stop doing so until toggled off.
Meanwhile, if you file an issue about this on GitHub, that would be awesome, so we won’t forget about it!
Oh, I see. The slowing down too much part I understand (it times out). Too fast - there’s no timer for that, if the firmware notices the key releasing, and being pressed again within the time limit, it will toggle. I would suspect a too light touch. One way to verify that would be to use the KeyLogger plugin (see warning later), and using - say - the Arduino IDE’s serial monitor to see if the keyboard sees the second press. If you go down this route, and need help figuring out the logs, let me know. I can prepare a short script for you that would listen on the virtual serial port, and time one-shot presses, thus helping us figure out what the firmware sees.
Note that the KeyLogger plugin is NOT part of Arduino-Boards (because reasons, whopsie!), so you’ll have to clone it separately.
2 Likes
Haha! by the time we get through this I’ll have every plugin there is active.
I’ll be more mindful of double tapping. I think now, having paid a little more attention, I possibly wasn’t fully releasing the key between taps, because I’m not having trouble otherwise with the keyboard registering events. It should not be hard to train myself in either case.
The L/R cancel issue has been added.
1 Like
If you configure your keymap such that the left and right modifiers both send the same keycode, would that not result in the desired behaviour (e.g. either control key cancels control-lock)?
1 Like
It would, but then you lose the ability to distinguish left from right. That may or may not be an issue though, depends a lot on whether one has key bindings that require right control (or AltGr, etc).
I moved the docs to the wiki:
much work still to do, but hopefully they are enough to help folks who get keyboards this weekend get started.
Input welcome!
I like the way this project manages their wiki, so it’s my model:
Here’s their blog post on setting it up:
https://labs.inn.org/2014/05/19/applying-git-to-github-wikis/#fn-1
@jesse I know what some of those git words mean, and am actively working to get to the point that I can edit locally and push to the wiki, but it’s not working yet, so for now I’m relying on cut and paste. I’ll get it all plumbed up soon, but am not sure how to check to see if the wiki permissions are set to support the contribution method they have documented.
The thing I would most like to see that I don’t feel 100% competent to create myself right now is a friendly table that shows keycodes and explanations of what they do. It doesn’t need to be complete, but at minimum should include all the keycodes in the maps that ship with the Model 01. I know there are .h files that list everything and I have the references to them, but they are a bit obtuse, particularly when they stray away from the alphanumerics and basic punctuation.
ETA: I want to turn “Home” into a quicklinks page like this:
1 Like
Any progress on the “clever #ifdef” solution? if not, are there existing keymaps for Dvorak and Colmak that match the .svg layouts? I would very much like folks looking for the alternate layouts to have the maps built for them on day 1.
Oh, I have a Dvorak mapping:
const Key keymaps[][ROWS][COLS] PROGMEM = {
[_DVORAK] = KEYMAP_STACKED
(
XXX , Key_1 , Key_2 , Key_3 , Key_4 , Key_5 , Key_LEDEffectNext ,
Key_Backtick , Key_Quote , Key_Comma , Key_Period , Key_P , Key_Y , TD(TD_BRACES) ,
Key_PageUp , Key_A , Key_O , Key_E , Key_U , Key_I ,
Key_PageDown , Key_Semicolon , Key_Q , Key_J , Key_K , Key_X , Key_Escape ,
LeftControl , Key_Backspace , Key_LeftGui , Key_LeftShift ,
ShiftToLayer(FUNCTION),
M(MACRO_ANY) , Key_6 , Key_7 , Key_8 , Key_9 , Key_0 , Key_KeypadNumLock ,
Key_Enter , Key_F , Key_G , Key_C , Key_R , Key_L , Key_Slash ,
Key_D , Key_H , Key_T , Key_N , Key_S , Key_Minus ,
Key_RightAlt , Key_B , Key_M , Key_W , Key_V , Key_Z , Key_Equals ,
Key_RightShift , Key_LeftAlt , Key_Spacebar , Key_RightControl ,
ShiftToLayer(FUNCTION)
),
1 Like
thanks! Alternate layouts wiki page is here:
I tweaked on the whitesapace a little bit to make it match better.