oliver thurley

Thoughts on customising a split keyboard layout

Wed, 12 Mar 2025 00:00:00 GMT

Earlier in the year I started experiencing pain in my wrist and hand. "RSI has finally come for me!", I panicked. After falling down a rabbit hole of ergonomics, desk setups, trackballs, and customised keyboards... I landed in an even deeper rabbit hole of split ergo keyboards. Fast forward through several Discord servers and subreddits, and now I’m typing on a Corne (aka CRKBD) 6-column/42-key split keyboard. I've had a lot of fun developing my own keymap, learning to type on a split, and finding an ergonomic approach that works for me. Maybe some of this will resonate with you too.

You can find the ZMK configs to install this yourself on GitHub.

UPDATE (22 June 2025): I designed my own split keyboard, TEMPEST, which you can read a bit about here, along with an improved keymap!

The Keyboard

For those unfamiliar, the Corne (aka CRKBD) by foostan is a split 'ergonomic' keyboard, with 3x6 columns and 3 thumb keys on each side. It comes in two switch styles: Cherry MX and low profile Choc.

I'm currently using a low-profile choc wireless Corne from Typeractive.xyz. It's fitted with Ambients Twilight silent linear switches, which are wonderfully quiet. I'm using ZMK firmware. I've heard some people complain that the choc-spaced board is cramped, but I've not had any problems with it. I'm currently just using FR4 plates in lieu of a case for an ultra minimal feel!

My Keymap

I've really enjoyed tinkering with this, and while the majority of it is fixed, I'm sure I'll keep making changes in some regard.

Inspired by Mark Stosberg's approach, I set a few key priorities for my own keymap development:

QWERTY. I regularly need to switch keyboards at work. While I love the idea of learning COLEMAK, brain space says no.
Easy access to symbols and navigation. I type 'normally' and code, and I want both to be easy. I think my initial RSI issues have something to do with constantly reaching for ; and => (){ ... thanks JavaScript!
logical layer arrangement. That means trying to consolidate layers but keep them clear and (relatively) easy to learn.

Finally, I've borrowed heavily from Manna Harbour's Miryoku layout, which is a thing of beauty and I would love to adopt... but it's design philosophy is rooted in 36 keys, and 42 seems to undermine that.

Base layer

No surprises here --- it's QWERTY.

[EDIT: added home row mods]

Left side thumb keys, left to right: Ctrl, Space (held for Nav layer), Tab (held for Utilities like Bluetooth). Right side thumb keys, left to right: Enter (held for Num layer), Backspace (held for Symbol layer), and a sticky Shift. I’m still not completely satisfied with this setup—see ‘Frictions’ below for more details.

One of my biggest dilemmas was deciding where to place modifier keys like Ctrl, Shift, and Gui (OS). Doubling up Ctrl and Shift isn’t the most efficient choice, but it has proven useful. I can see this is where home row mods have a definite advantage, and one I'm considering.

[EDIT: I've tentatively started playing around with Home Row Mods after reading this excellent guide. I'm enjoying it, although I am encountering a LOT of mis-fired mods on regular typing, so I need to adapt my typing style if I'm going to commit to it...] [UPDATE: okay, I'm more used to it now... I love it!]

I'm using a couple of combo presses here too:

G+H for WORD_CAPS
T+Y for CAPS LOCH
Q + W for Escape
del + ' for volume up
' + alt for volume down

Navigation layer

This one borrows heavily from Miryoku, but I've consolidated arrow key navigation and mouse control onto one layer. I'm still unsure if the trade off is worth it, but it's mostly working for me at the moment.

I think a big part of my RSI issue stem from reaching for the mouse. To that end I'm using a trackball, usually positioned between my split keyboard. Ultimately I like the idea of using the keyboard itself to do a lot of the mouse navigation I'm used too... but I'm not there yet. (I think the next hurdle will mean finding a decent window manager app for windows.)

Symbol layer

This layer was the hardest to get right, but while I continue to tweak elements, I'm pretty happy with it for the most part.

The focus for this layer was comfort when programming, so things like brackets and basic operators need to take preference over lesser used symbols. To aid learning I've tried to group symbols somewhat.

I'm working in JavaScript a fair amount, so I have a handy double tap dance on my > key to give me => for arrow functions.

Number layer

A simple one: numbers across the home row, function numbers above. I've got the shifted number keys along the bottom row but I don't really use them favouring the symbol layer instead.

Utility layer

For now, this layer is minimal, mainly handling Bluetooth profiles. However, I expect it to evolve as I get more comfortable with ZMK.

Frictions

Right now, my biggest friction point with this keymap is the placement of the inner thumb keys — Ctrl on the left and Shift on the right.. For example, relatively common combos like Ctl + V or Shift + N mean I have to move my thumbs under my palm and my index fingers out, which is uncomfortable. ~~This is something that makes me consider home rows, or even just using the sixth (outer) columns more.~~ [EDIT: home row mods and sticky shift have helped this, but I'm now working on my own keyboard design to push the thumb keys out wider...] [UPDATE: I finished it! My new keyboard TEMPEST, which you can read a bit about here]

Reflections

On the whole I'm happy with this setup for now. Will my setup evolve? Absolutely. I'm still slower and more uncertain typing split than on 'regular' keyboards, but my RSI issues have abated. I’m not claiming that my keyboard cured anything, but improved awareness of my typing form, posture, and the use of a trackball (Elecom Deft) have all made a significant difference. And I think, above all, I've found this whole learning and development process fun!

Considering a split keyboard?

Do it! As I've said, it's fun, and clunky, and slow. But I'm happy to be doing it, and every day I'm getting a little more confident and faster. I'm still nowhere near my normal keyboard typing speed, and maybe I never will be, but I'm okay with that as speed isn't my reason for doing this.

Choc vs MX

I started out with a wired MX Corne v4.1 with 46 keys (2 extra on the inner sides), with Outemu v3 Silent Peach switches and VIAL firmware. I was happy with the layout, but quickly realised that the wired connection was cluttered and bothered me, so I moved to a wireless Choc version.

I'm using the 6-column variety. Initially I thought that more keys would require less layer-hopping, and therefore make for an easier transition from my usual 75% and 100% keyboards. What I wasn't anticipating was how different the initial typing experience was. Even though I've stayed with QWERTY (I need to use a variety of computers at work) typing on a non-staggered split keyboard was completely alien and I needed to effectively relearn to type from scratch. Now that I'm mostly through that and onto the other side, I can't help but feel the sixth column is a little superfluous... and the 36-key (5 column) model looks nicely compact. If I do want to downsize, I don't anticipate a huge amount of changes to my setup besides maybe home-row mods. [I'm currently designing my own board inspired by the Temper / Bad Temper and TOTEM boards...]

Useful resources

I've found these helpful in experimenting with different layouts:

Corne GitHub
ErgoMechKeyboards subreddit
MechKeys, ZMK, and Typeractive discords
Miryoku layout - 'an ergonomic, minimal, orthogonal, and universal keyboard layout.'
Mark Stosberg - excellent article about the development of a personal layout
KeymapDB - repository of user keymaps
'Designing a Symbol Layer' - Pascal Getreuer article, 2021/23
Learning to type on a split keyboard is a nightmare. I'm practicing with keybr.com and monkeytype.com.
For ZMK, Nick Coustos has a nice visual editor for keymaps: https://nickcoutsos.github.io/keymap-editor/ which compiles firmware through GitHub Actions. (But I still haven't found a workflow as smooth as "live" VIAL updates)
A Guide to Home Row Mods - precondition
Urob's ZMK resources

Close out

Disclaimer

This is my personal keyboard layout and subject to change at any time.

Keymap images were made with https://www.keyboard-layout-editor.com/. You can find my KLE jsons here: Base, Symbol, Navigation, Number

Get in touch

Have any questions or thoughts? Are you on a similar keyboard journey? I'd love to hear from you via social media, email, etc.

Update 25/03/2025

I've been playing with Home Row mods a lot for the last week or so since publishing this post, so much so that I've merged them and published my ZMK config on GitHub. Besides the HRMs there isn't really much differece to the layout above.

Update 25/05/2025

Read more about my new custom keyboard, TEMPEST. There's also some nice new keymap things there.fs

Building My Markdown CV Workflow: One Source, Multiple Formats

Fri, 20 Jun 2025 00:00:00 GMT

As someone in the face of a turbulent job market I quickly found myself grappling with an unexpected but recurring frustration: my CV. Not the content itself, but the process of managing it. I needed different versions for different contexts: a clean markdown version is nice to write, but I need a neatly typeset PDF for job applications, a Word Docx for recruiters, and a simple, readable web version I could share as a link. And each time I updated one, I had to manually replicate those changes across the others.

This small pain point gradually became more than just an irritation. It became an opportunity for an automation project...

Automation, XKCD #1319

The Problem: Format Fragmentation

Over the past few years, I’ve maintained a CV in Google Docs, a LaTeX version for academic use, and a stripped-down plain-text version for job boards or technical applications. Keeping them in sync was tedious. Sometimes I’d update the Google Doc, forget to update the LaTeX file, and end up submitting a version that was months out of date.

Worse still, each format had its own quirks: spacing and formatting in LaTeX, markdown rendering issues on GitHub, and limited styling options in plain HTML. I wanted a workflow that gave me one single source of truth, from which I could generate all the required formats: PDF, markdown, and a web-friendly version.

The Solution: A Single-Source CV Repository

I decided to treat my CV like a software project: version-controlled, modular, and automated.

The result is my CV workflow repository. At its core, it’s a small, structured codebase that builds my CV in multiple formats from a single markdown file. Here's how it works:

CV Content in Markdown
I write and maintain the actual CV content in a human-readable markdown file (creatively titled cv.md). This keeps it portable, lightweight, and easy to edit in any text editor. A small YAML header gives variables like author's name, email, social media handles that can be injected into different format templates.
Format conversions Pandoc handles the various conversions using format templates. I have templates for HTML (with a simple CSS stylesheet), DOCX (with a simple font styles --reference-doc, because DOCX doesn't support templating), and a TEX template for rendering the LaTeX version that is in turn used to create the PDF version. These produce clean, professional documents with consistent formatting every time.
Live Web Version
By setting up the repo to be hosted with GitHub Pages, the HTML version gives me a live, public-facing CV at a consistent URL—always up-to-date and readable on any device.
Auto-updating and CI With GitHub Actions, I’ve set up automation so that every push to the main branch triggers a rebuild of the web version and regenerates the other version. It commits these back to the outputs/ folder (as well as the Action's Artifacts) so I can easily access or point to them. The master branch will always be the most up-to-date version.

All I have to do is update the markdown and commit—it’s fully hands-off after that.

Want to Use It? I Made a Template

If this kind of workflow would be useful to you, I’ve made it easy to get started: I’ve turned my setup into a template repository you can fork. It comes preconfigured with everything you need:

A clean markdown structure for your content
Scripts to generate web and PDF versions
GitHub Actions for automated builds
Styling that’s easy to customise

You can fork it directly, plug in your own details, and deploy your own live CV in just a few minutes.

Why This Was Worth Doing

Aside from being an immediately useful tool for managing my own CV, this project ended up doing a lot more:

Version control lets me track changes over time and tailor versions for different types of roles.
Live shareability means I can send someone a URL instead of a file.
Reusability makes it adaptable for other document workflows: cover letters, portfolios, or academic bios.
Showcase: It’s also a nice project to point to when applying for roles—demonstrating templating, markdown processing, static site generation, CI/CD pipelines, and PDF export.

Final Thoughts

What started as a simple attempt to clean up my CV workflow turned into a genuinely helpful tool—and one that I hope others will find useful too. If you’re looking to streamline your CV management, feel free to check out the template on GitHub.

The best kind of project is one that solves your own problems—and can then go on to solve someone else’s too.

TEMPEST: Designing A Custom Split Keyboard

Sun, 22 Jun 2025 00:00:00 GMT

After a little while building and adapting split keyboards, I decided to design one for myself: TEMPEST — a low-profile, wireless, 36-key split keyboard.

TEMPEST reflects everything I’ve learned so far about what makes a keyboard genuinely comfortable and enjoyable to use, what works for me, and more than a few blunders in PCB layout.

This project builds on ideas I wrote about in “Thoughts on Customising a Split Keyboard Layout”, where I detailed the process of adapting to split ergo layouts, rethinking muscle memory, and designing a keymap that worked for me. With TEMPEST, I wanted to take that further—not just adapting layouts to existing hardware, but shaping the hardware itself around my hands, workflow and habits.

The full repo, with Gerbers, KiCad PCB, 3D-printable case, and ergogen design files is here: https://github.com/thrly/tempest. ZMK firmware configs and keymap layout can be found at: https://github.com/thrly/tempest-zmk.

Why Build a Keyboard?

It started with small frustrations: thumbs too cramped, pinkies overworked, layout compromises dictated by PCBs etc. I love my Corne keyboards, and others in the community like Sweep, TOTEM, and Chocofi look excellent... but none of them felt like mine, so I wanted to try making something that solved all those "if this thing was a little bit more __" issues.

Designing my own keyboard would let me integrate all the things I’d grown to prefer, cut the things I didn’t need, and, perhaps most importantly, own the full workflow: from PCB to firmware to daily use.

I should start by saying, my electronic knowledge is very basic. I've soldered modular synthesisers from kits, but never designed anything myself. Thankfully, keyboards are actually pretty basic in terms of circuitry, and tools like ergogen made the layout process ridiculously easy. This guide by FlatFootFox walked through the whole process and the KiCad routing. I would have been completely lost without it.

Design Goals

My staring point was my beloved Corne (the choc version from Typeractive specifically. As I say, I love it, but there are some things I don't love and wanted to change.

With TEMPEST, I aimed for:

36 keys: A minimal layout (3x5 + 3 thumbs) that forces thoughtful layering and cuts away redundancy. Thumb cluster is spaced out a little wider than the Corne.
- (In an earlier version I played with snap-off extra outer keys, like the TOTEM but couldn't make the PCB routing work).
Custom column stagger: A little more pronounced that Cornes, and based loosely on my finger length and reach — especially important for the pinky and ring fingers. I also added some slight splay to the ring and pinky columns, again, a la TOTEM.
Low-profile Choc switches: Nice and comfortable, I love my Ambients Twilight for long sessions and great for portability.
Wireless-first design: Powered by nice!nano controllers and onboard integrated battery support. This all follows the Typeractive Corne build which I think is excellent.
- I tried to add nice!view display, but screwed up the connections on v 1.1, so this doesn't currently work...
ZMK firmware: I’ve grown to prefer the workflow and customisability of ZMK, especially its support for home-row mods, combos, layered design, and the GitHub automated build.
Reversible PCB: Makes for more cost-effective fabrication, and there's a certain elegance to it.
Simple low-profile 3D-printed case.

All of this is designed in Ergogen + KiCad and then hand-assembled. The result is a clean, compact board that’s become my daily driver at home and on the go.

Firmware and Layout Philosophy

ZMK has become central to my keyboard setup. The firmware workflow (especially now with GitHub Actions) allows me to treat firmware the same way I treat code—versioned, repeatable, and documented. The TEMPEST repo builds firmware automatically with every change, making experimentation easy. I wouldn't say its totally frictionless, as you still need to manually flash the new firmware via USB for each change, which is a pain.

The layout follows principles I wrote about previously on “Thoughts on Customising a Split Keyboard Layout”:

Mod-taps for home-row modifiers.
Layered access to symbols, navigation, and media keys.
Thumb-focused design with three keys per side — one for space, one for layer switching, and one for backspace or enter, depending on the context. (I've also added a mod-morph to easily add underscores WHEN_WRITING_IN_ALL_CAPS, which is nice.)
Combos and sticky keys to reduce awkward reaches. I've really been getting into combos on the default layer on a 36-key layout. Common things like -_'"
- I added a cheeky F19 macro on q+t+y+p which Autohotkey returns as console.log( Take that JavaScript!

After lots of of refining and daily use, the layout feels second nature. The consistency in structure makes relearning layers on different devices (or different computers) much easier. I no longer think about where things are — they just are.

BONUS: On the config repo, I've used the brilliant Keymap Drawer by caksoylar to produce automated layout diagrams each time the keymap is updated.

Takeaways and Lessons Learned

Designing TEMPEST wasn’t just about soldering and scripting — it was a full-stack project. Here are a few key lessons from the process:

Start with use cases, not features. It’s easy to get caught up in extras (RGB, encoders, OLEDs), but focusing on how I actually type helped me prioritise the core layout and form factor first.
The thumb cluster is everything. I think many boards get this ~wrong~ cramped. Iterating on placement, angle, and spacing made a bigger difference than almost anything else.
Muscle memory takes time, but it pays off. A minimal layout forces you to be intentional. At first, it’s frustrating; over time, it’s freeing.
Wireless has trade-offs. I love the tidy setup and portability, but wireless introduces extra debugging and some latency trade-offs, especially for certain workflows (e.g., gaming). That said, for writing and coding, it’s been rock solid.
Designing PCBs is empowering. Even with the learning curve of KiCad, being able to iterate on physical design is liberating. It’s coding, but for your hands.

Most importantly: making your own keyboard turns typing from a task into a craft. You’re not just pressing keys — you’re engaging with a tool you’ve built, shaped, and refined. Every time I type now, I get a smug, satisfied feeling that I made this. (To counter, everytime something goes wrong with it, I'm entirely to blame...)

Final Thoughts

TEMPEST might not be the end of my keyboard journey — there are always new ideas to try and I've already got plans for v2 — but it’s the first keyboard that feels complete for my current needs. It’s the result of lots of iteration, both in code and hardware, and I’m genuinely proud of it.

If you’re curious about the layout, want to build one yourself, or fork it for your own experiments, the full repo is here: https://github.com/thrly/tempest

Happy building — and if you do make your own version, I’d love to hear about it.

Lastly, credit to the keyboards that inspired and informed TEMPEST:

Corne by foostan (and the Typeractive version)
TOTEM by GEIST
Temper by raeedcho
Bad Temper by essFitt
FORAGER by carrefinho
Chocofi, Sweep, and others.

Softening Edges: Chaikin’s Algorithm in Generative Art

Fri, 04 Jul 2025 00:00:00 GMT

In many of my generative sketches, I start with raw geometry: a jagged polygon, a noisy perimeter, or just a random set of coordinates. These tend to feel too rigid, too mechanical... too sharp. What I often want instead is a way to soften that geometry, to make it feel more fluid, more organic. One of my favourite ways to do this is by applying a few iterations of Chaikin’s corner-cutting algorithm. I used it heavily in my series WAVETABLE: four fucked waveforms (2024):

Chaikin’s method is simple: it smooths a path by iteratively “cutting corners” by a set ratio. For each pair of points, it inserts two new ones slightly closer to each end, then repeats the process as many times as needed. The result is a sequence of points that approximate a smooth curve, without needing to touch splines, control handles, or Bézier maths.

How It Works

Given a set of points for a polyline or polygon:

For each pair of consecutive points (A, B) of a segment, calculate:
- Q = 0.75 * A + 0.25 * B
- R = 0.25 * A + 0.75 * B
Replace the original segment with the new points Q and R.
Repeat for a few iterations.

This gradually rounds sharp corners, and after several iterations the shape converges toward a quadratic B-spline. The resulting form is still defined entirely by your original path—just softened.

Code example

Here's an implementation I use in my chaikin-curve repo:

function chaikin(point_array, n_iterations) { // point_array is a set of x,y coords
  let smooth_array = [];
  for (let iter = 0; iter < n_iterations; iter++) {
    let temp = [];
    for (let i = 0; i < point_array.length - 1; i++) {
      let p0 = [point_array[i][0], point_array[i][1]]; // segment start
      let p1 = [point_array[i + 1][0], point_array[i + 1][1]]; // segment end
      let q = [0.75 * p0[0] + 0.25 * p1[0], 0.75 * p0[1] + 0.25 * p1[1]];
      let r = [0.25 * p0[0] + 0.75 * p1[0], 0.25 * p0[1] + 0.75 * p1[1]];
      temp.push(q);
      temp.push(r);
    }
    point_array = temp.slice();
  }

  // then add back in start and end points
  point_array.splice(0, 0, [points[0][0], points[0][1]]);
  point_array.push([
    points[points.length - 1][0],
    points[points.length - 1][1],
  ]);
  return point_array;
}

Why Not Just Use Bézier Curves?

A fair question. Libraries like p5.js give you Bézier curves and curveVertex() for free. So why reach for Chaikin?

Chaikin' corner cutting doesn’t require precise control or knowledge of Béziers. It works with whatever geometry you give it. No need to think about angles and control points. It’s ideal for softening the edges of generative shapes — messy blobs, grid-based forms, even text outlines — where the goal is aesthetic rather than mathematical precision.

Sure, curve() might give me an equally good result in most cases, but having a more custom solution is handy sometimes.

SigHack's excellent post on Chaikin curves (in Processing) gives some really nice use cases: from softened voronoi cells, to brush strokes.

Chaikin’s algorithm won’t replace Bézier curves and splines, but it’s an excellent tool to keep around when you're working procedurally and want a bit of softness.

oliver thurley

Thoughts on customising a split keyboard layout

The Keyboard

My Keymap

Base layer

Navigation layer

Symbol layer

Number layer

Utility layer

Frictions

Reflections

Considering a split keyboard?

Choc vs MX

Useful resources

Close out

Disclaimer

Get in touch

Update 25/03/2025

Update 25/05/2025

Building My Markdown CV Workflow: One Source, Multiple Formats

The Problem: Format Fragmentation

The Solution: A Single-Source CV Repository

Want to Use It? I Made a Template

Why This Was Worth Doing

Final Thoughts

TEMPEST: Designing A Custom Split Keyboard

Why Build a Keyboard?

Design Goals

Firmware and Layout Philosophy

Takeaways and Lessons Learned

Final Thoughts

Softening Edges: Chaikin’s Algorithm in Generative Art

How It Works

Code example

Why Not Just Use Bézier Curves?

Related links