1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
|
# 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](https://semilin.github.io/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
# Credit
Cherry MX6C ULP and Kailh low profile switch footprint with through hole soldering cutout copied from [DELTA OMEGA](https://github.com/unspecworks/delta-omega) and licensed under [CERN-OHL-W-2.0](https://github.com/unspecworks/delta-omega/blob/main/LICENSE.md).
|
