Column assumptions

[Llamalland]

First of all, i really love how much more detail you put into your notes everywhere, especially the core.clj and build.md files. It's helped me get a decent distance with my problems already.

That said, I'm running into a bit of a wall. I think (and I ran into this problem with the dactyl manuform too) that it's assumed any more than 6 columns are extra columns lateral to the pinky column(s), whereas I want a 5x7 (well really actually 4x7, but more on that later) design where 5 of the columns are part of the typical 5x3 typing mask on each hand (one for each finger, but index finger handles an extra column) and then an extra column either side of that (in fact, an entire left/top/side border around it). I can understand why people might not want to move their index finger 2 columns across, but it makes sense to me for specific keys that aren't used so often. It certainly makes more sense to me than moving my pinky 2 columns across.

So to try to fix this, I was able to find values that related to columns and shift them so they made sense, and that seemed to work for the main body. However, there were problems caused by that:

1. The thumb cluster was now too far central. Easy fix by moving the thumb offset, you'd think, but now I have a random join over one of the thumb keys, presumably at a point considered as "no-one would want their thumb cluster where this would interfere - you don't move your thumb underneath your middle finger!" but it's under the index finger in my scenario, which I absolutely do.
   

2. I could be wrong about this, but I think some interaction of assumptions about what columns are likely to jut out the most and some of my changes to get columns where I want them have thrown off the curve of the back, making it look a lot less compact than the normal design.
   

So about the 5x7 layout, I have never quite understood why dactyl-style keyboards say n columns but actually mean n-1 columns except in some specific spots. I hate that, and what I really want is 4x7 (but I need to say 5x7 to get 4 on some of my columns).

I changed

(defn place-key-at? [[i j]]
(and ((set columns) i)
((set rows) j)
(or (#{2 3 (column -1)} i)
(< j (row -1)))))

into

(defn place-key-at? [[i j]]
(and ((set columns) i)
((set rows) j)
(< j (row -1))))

which seemed to fix it, but left a big t-tetramino-shaped hole in the body. Maybe it would be useful to be able to define another operation which throws flat body pieces into defined key positions?

I hope this all made sense. I wish I could attempt more of a fix, but I have no idea what I'm doing with 3D object design or with clojure, so any help would be greatly appreciated!

[dpapavas]

Sorry I couldn't get back to you earlier, but I was away during the holidays. You're right I'm afraid that your desired design does clash with the assumptions I made while designing the Lagrange. Making the design truly parametric isn't really feasible, as the "degrees of freedom", so to speak, that is, the different cases that have to be taken into account in the code to ensure a correct build with arbitrary parameters, grow exponentially. To be honest, talking about "design assumptions" isn't really accurate either. The Lagrange was designed to be what it is. Some design parameters were made configurable by using adjustable variables, mostly to facilitate development and with the hope that one might change them (slightly) and still get a working build. Some areas are less problematic than others in that respect.

The problem in your case, is that the design choice that the thumb section is joined to the main section at the second to fourth columns is hard-coded. It also affects most of the design really, so changing that won't be easy. I made several attempts to hack the code to get something like what you want, even if it is not accomplished in a very robust way, that is fit for publishing, but I haven't had much luck. To be honest, I probably have currently as much knowledge of the code and of Clojure as you, since I haven't worked with either since I finished the design.

The only approach I can think of, that should work, would be to set column-count to 7, adjust row-phase and thumb-offset to get the overall height right and to get the thumb section where it needs to be and then rework all of the top geometry, connecting the key plates to the walls (the "webs") and probably part of the side walls, to get a valid build. I'm afraid this means you'll have to get acquainted with the code, as large-scale changes will be required. As far as I can see (although this is just a guess really), it shouldn't be too hard, programmatically speaking, but a lot of trial and error will be necessary, to find and implement a working design, in terms of geometry. You'll mostly have to look at the definition of connectors plus the code for the walls, below it. You'll probably also have to do several trial prints to make sure the geometry is ergonomically sound.

PS: You're right that most of the columns have one less key than advertised, but, seen the other way around, two of them have one more key than the others, mostly because they can, being rotated upwards for ergonomic reasons anyway. You can get rid of that, but you should probably keep the test as (or (= (column -1) i) (< j (row -1))), unless you want to get rid of the palm key too.

[Llamalland]

So in the end I found diykeyboards/joshreve's project easier to modify into what I wanted, moving thumb keys into a palm/thumb knuckle location (I'm typing this on a model 100, love palm keys) and a few of the other things I mentioned, as well as realising your palm/pinky knuckle key is one I like the idea of, but probably wouldn't use, as with the mid-tier thumb keys.

I am still hoping to get your stand and corresponding holes in the base into my project.

Anyway, thank you for your help, and especially for provoking a lot of productive thought!