Hrm. Can you elaborate a bit, and perhaps come up with an easy example? I’m not sure I fully understand.
Even without that, in Spacemacs, for example, I can have buffers where I use modal editing, and others where I don’t. There is no possible way to follow that without editor assistance.
What is possible, is to have generic chord reactions: you press a layer key, and keys that change behaviour, light up, with pre-defined colors. Or you press a modifier, and the whole keyboard’s color changes to reflect that, pressing multiple modifiers blends the color. Those are all possible without any kind of communication, and are still useful - I think -, even if less so than the possibilities with editor assistance.
This would only work with some chords so it might not work great, but you would have to enumerate the chords. A list of chords in a file. Then just read that file to determine each next letter in a chord.
,rs
,rf
,rl
,gs
A file like that could be used and after a , light up r and g. Next if an r is hit we would light up s, f, and g. I think it would be difficult and would have to have place holders to be useful. ie. d<num>d.
I see. The LED animation scripting is nonessential, but would be neat. I’m fine doing that kind of stuff myself.
As for Lua, I can see how having an interpreter on the firmware would be infeasible. Lua is pretty small, but apparently not small enough. Converting Lua to C sort of defeats the purpose of using it. Perhaps a compromise could be made using some kind of RPC. I’ll think on that a bit more and see if I can come up with anything that conforms to the hardware limitations. It’d be very convenient (and fun) to rapidly prototype or create one-off scripts.
Easiest would likely be a very simple command interface, and then the work is off-loaded to the host. That’s reasonable on the firmware side, but is far less portable, as you need to install the controller program on the host, and possibly port it to a number of OSes. (But then, when using Lua, there would only be small things that differ between OSes, so the porting effort would not be all that much.)
That’s exactly what I meant by a RPC. Lua has portable 3rd party socket/serial libraries available. Python has basically everything under the sun. If the firmware had an interface available that listened for commands and acted on them accordingly, you could do all the scripting on the host in whatever language people cared to write interfaces for.
Added a Space Cadet Shift idea to the list. It is something I saw people use with QMK, and is a neat idea if you have two shifts anyway. Goes well with the Ctrl/Esc pair, too, and builds on the same foundation.
One thing I look forward to is to implement something like the Velotype chording map in firmware. The patent (http://www.google.ca/patents/US4804279) has expired by now… It would be great if that would fit in the firmware and be switchable.
Furthermore, I think bi-directional communication with the editor would be very useful; on the kickstarter comments I’d already alluded to possibly highlighting only syntactically valid completion letters based on where in the source code one is; consider this the more advanced version of the chording proposal, but integrated into the syntax highligher/intellisense/omnicompletion stuff in the editor or IDE.
Another good reason for bi-directional communication is automatic mode switching from one application to the next; e.g., in my e-mail client I’d probably be typing regular text more, so a mode that is optimized for typing long stretches of text would be great, but in my IDE I’d prefer my symbols to be more readily available. Having the keyboard switch ‘by magic’ sounds like a great idea at the moment.
Ofcourse, this is all dependent on the power of the embedded AtMega… it might turn out to be useful to beef the thing up sometime in the future, using e.g. an ESP8266 hidden in the casing.
That should be possible, if the chording map does not require a big dictionary. I have not read the patent, but the Wikipedia article suggests that the dictionary would be rather small.
One of my goals is to learn Plover in the next few years, and now that I read a bit about Velotype, perhaps it would make sense to learn that first, as an interim step. So I’m looking forward to playing with your implementation!
I’ve been thinking more about what I might want the LEDs to do. In particular, if I could have an on-keyboard heatmap mode, I’d want it to be context-sensitive to some extent. In other words, I’d want it to store that data in separate counts depending on the layer (and perhaps chorded modifiers, if there’s a difference – the definition of “layer” isn’t fully clear to me). So if I have the LEDs in heatmap mode, it should display the heatmap for the current layer/modifier.
The other thing I’d want the LEDs to do is to give a visual indicator when switching modes. Most obvious would be switching from one OS mode to another. It would also be nice to highlight keys used that temporarily change the behaviour of the keyboard, such as dead keys, one-shot modifiers, compose keys, and the like. That way, if there’s a timeout (I think any Caps Lock should time out after a few seconds without a keypress), the user could tell at a glance whether or not it’s still in effect.
I can make a heatmap plugin that’d do this, but the memory use of such would be big. The current implementation uses 69 bytes just for the heatmap data, so that’d be 69*(layers+mods)… and modifiers would be an issue, since you can have modifiers on a layer - do you want to count that for the layer, for the modifier, for both, or do you want modifiers/layer?
Based on my heatmap experiments on the ErgoDox, a heatmap for modifiers is almost completely useless, so I’d suggest just going with per-layer heatmap. That’s a reasonable thing to implement, and the data use would not be terribly huge, either.
This is reasonably easy: the macro you use to switch from one mode to the other, would do some LED effect, too. You don’t need a plugin for this, just macros and docs.
This is something I had in mind, too. My idea was to make it easy to create a color map, and have a plugin that applies a color map for each layer, blending the colors in the map with whatever is already on. So you’d be free to color keys with any color you like, for any layer. This would make it possible to have different colors for the mouse and the cursor keys on the default Fn layer, for example.
What is the formal distinction? I’d like to have well-defined terms, but “layer” is still not clear, especially in the case of a keyboard as extensively programmable as the Model 01.
I guess it would be useful to have one per layer, though it would be nice to distinguish between keys typed chorded and not chorded. For example, I type (on QWERTY) the letter c with my left middle finger, but Ctrl-c with my left pinky on Ctrl, but my left index finger on the c. I’m thinking that the small amount of memory on-board will simply make it impossible to record the data I’m interested in.
I had something a bit different in mind, I believe. I had also thought of using the LEDs to indicate in some way the changing function of keys on different layers (or with different modifiers, but maybe there’s not enough memory for that) as you described, but what I was thinking of this time is easier to describe by example.
Suppose I have a compose key. I press and release it, and that key lights up, letting me know it’s active. Nothing else lights up at this point, but if I go a few seconds without typing another key, it times out and does nothing, and the light turns out to indicate that. When the compose key is active, I then type another key (e.g. '), which also lights up, then a third (e, to make é), and both lights turn off.
I’m considering trying various locked modifiers, too. Suppose I press and release Shift (or Control) to get a one-shot modifier, but I want it to time out after a few seconds in case I’ve forgotten what I was doing, or changed my mind. But sometimes I want it to stay on until I turn it off, which I would do by typing it twice (or maybe typing both Shift keys simultaneously, if I have two). That light could be a useful indicator that it’s still on.
The difference is in that the USB HID spec knows about modifiers, but it doesn’t know about layers. Other than that, they are very similar indeed.
Yup. And your data would be very limited in precision too. Instead, if you want more data, with better precision, which you can analyze anyway you want, I’d suggest using a key logger (within the keyboard), and an custom tool that analyzes the data. For the ErgoDox EZ, I have such a tool, and it can generate heatmaps, and stats too:
The problem there is that a keylogger cannot distinguish between two different ways of entering the same scan code – only the keyboard has that information. And if I use certain keys as dead keys that don’t get transmitted to the host computer, that information is completely lost. I’m rather disappointed that there won’t be enough storage on the controller for what really doesn’t amount to a lot of data.
Alas, my ideas for the LEDs seem to be much more trouble than they’re worth; I’ll probably just leave them turned off all the time.
The keylogger would be built in the keyboard, and then it can. The way I have it set up now, is that the keylogger sends the row, the column, the pressed/released state, and the layer. Then the analyzer on the host can figure out what was pressed at the same time, on which layer, and so on. No information lost.
Well, the RAM on the controller is about 2k, and a lot of that is already used for other things that make your keyboard work. At best, there would be about 1.5k left free. If we use a 8-bit counter for each key, we are looking at about 69 bytes/layer, just for counters. If you want the chorded info too, then that’s about 69*8 bytes/layer, meaning you could have three layers at most. And the precision of a 8bit counter isn’t terrific, either.
So for advanced heatmap stuff, keylogger in the keyboard + smart analyzer software on the host is a lot better. If we’ll have a way to send LED data to the keyboard from the host, then this analyzer could send the processed data back, and thus offload a lot of data from the keyboard.
That is, what you want is possible, you can have that heatmap on the keyboard too, but we’ll need to do the main processing on the host.
Apart from the heatmap, the rest of the ideas are easy to implement the way you want them. Once the firmware and my plugins stabilize a bit more, I’ll show you an example
It’s the 2K of RAM on the controller that is shocking to me; that’s about three orders of magnitude smaller than what I’d have guessed it would have.
That aside, I did have time to read your description of the keylogger plugin, but I’m baffled. How does the controller send that information to the host computer? Is it emulating multiple USB devices simultaneously?
It does look like all the necessary detail is there…but to use it, I’d have to duplicate all my configuration work in a parser, or design a configuration parser that creates both the keylogger and the keymap. For the benefit I’d get from it, that still sounds like more trouble than it’s worth.
Hehe. Well, it’s a keyboard. Under normal circumstances, you don’t need much memory on it. The ErgoDox EZ, and most other ErgoDoxes except for the Infinity, use a Teensy2.0, which has the same amount of memory. It’s not uncommon to have very little RAM in these.
But even if it would have more memory, there would be some hairy obstacles to cross before a per-layer/per-modifier heatmap could be made fully within the firmware: in general, you don’t want to allocate memory at run-time, because that’s costy (in terms of RAM needed for bookkeeping). So you’d have to preallocate enough to hold all the data. Even if you don’t use that many layers, or all eight modifiers. That’d be terribly wasteful…
Yes, it is. It emulates an USB keyboard, an USB mouse, and an USB serial device. The logs are sent on the USB serial device.
I can add the keycode to be sent to the log too, that way you may not need to recreate the layout for the analyzer. But yes, there are things that you may need to do twice, but when you change the layout, there is little to change in the analyzer: just update the layout there, too. I’ve been doing that with my heatmap generator tool, and all I need to do, is update my layout on KLE, and update the JSON for the heatmap generator. No other change necessary. And I do that update anyway, so I can print a new cheatsheet
My personal experience is that having a good heatmap is an incredible asset, and writing the log parser & analyzer was well worth it. I’ll likely write something similar for the Model 01 too.
It would be great if that would fit in the firmware and be switchable.
