#srchr

A parallelised keyboard layout optimiser.

srchr uses a "genetic algorithm like" approach to keyboard layout optimisation. A tournament is held between N contestants, the best K of which are kept and used to seed the next tournament round. Seeding occurs by selecting a random contestant from the K above, and applying some configurable random number of random transpositions.

Key to the architecture of srchr is the design choice to use "pre-layouts" as opposed to layouts. Pre-layouts comprise only the data of columns of keys (three per non-index finger, six per index finger). Ordering of these columns and ordering of keys within these columns is not considered at all when generating and scoring pre-layouts (in particular keys are never transposed within a column). This architecture is useful, but limits us to evaluating metrics which do not depend on knowing where certain columns will be. For instance, there is no simple way to evaluate "lateral stretch bigrams" (LSB) because we do not know which columns belong to ring middle, let alone which way index columns will pair with ring columns.

However, it is nevertheless possible to recover some metrics under reasonable assumptions. For example, we assume that the two columns with the lowest usage will be assigned to pinky fingers, and so we are able to penalise pinky usage (although not handedness).

This architecture also necessitates a way to transform pre-layouts into layouts. For this purpose srchr implements two algorithms, viz., MinimiseLSBThenBalance and GreedyBalance and both share general assumptions about key placement by frequency. As suggested by its name, the former attempts to minimise LSB by pairing middle and index columns judiciously, and thereafter balance hand load evenly (subject to the constraint of left pinky usage being lower than right). Greedy balance on the other hand understands no such affordances and simply aims to (greedily) balance usage between hands. Neither of these are provably correct in all cases, but they are simple and produce reasonable results.

#usage

src/config.rs provides a number of configuration options, and frequency data may be loaded from a text file or parsed from a json file. Examples of both are included.

Once satisfied, run cargo run --release and enjoy.

#the resulting layout

With default parameters and the provided shai.json frequency data, the search seems to converge on

V L O M Z  W P U H .
S R A T K  G C E N I
X J ' D Q  Y F / B ,
Percent per key:
 1.06  4.12  7.59  2.42  0.10   1.81  2.08  2.87  4.61  1.11
 6.38  6.01  7.92  8.87  0.80   2.04  3.05 11.71  6.76  7.07
 0.21  0.17  0.48  3.65  0.10   1.92  2.12  0.08  1.49  1.03

Finger usage:  7.65%, 10.31%, 15.99%, 15.93%, 13.03%, 14.66%, 12.86%,  9.21%
Hand usage: 49.88% vs 49.75%
SFB distribution :  0.007%,  0.090%,  0.105%,  0.069%,  0.159%,  0.164%,  0.045%,  0.021%
DSFB distribution:  0.183%,  0.422%,  0.764%,  1.875%,  1.373%,  0.675%,  0.740%,  0.446%
Total sfb: 0.660%
Total dsfb: 6.477%
Total lsb: 1.881%

Using other, finer-toothed tools such as genkey this can be improved by making a transposition in each stretch column, Q <-> Z & G <-> Y, as well as interchanging P <-> F in the right index column. The result is "VLOM",

V L O M Q  W F U H .
S R A T K  Y C E N I
X J ' D Z  G P / B ,

#FPKB

Schematics for a 34 key, low-profile split keyboard, the raison d'être of srchr.

and it's v4 variant, with full size switches

#Copyright

See LICENSE & COPYING