josefadamcik
commented
3 years ago HI @AlexDaniel , thanks for all the input and feedback!
Regarding the first point: I think somebody already gave such feedback (even including the palm argument). I do appreciate the feedback, but in this case I am not going to change the design. I had the discussion in another issue so I am not going to repeat it here.
Regarding 2. -> I hear you and having low-profile support is still on the table. Removing it for version 2 was mainly to make rerouting easier for the sake of prototyping. I do have one problem with Kailh-choc switches (at least the ones available at the time) - they were too heavy to my liking. So heavy I just couldn't used them. And the important detail is, as you wrote, that "There seem to be several alternatives now, all of them being incompatible…". Here waiting a bit and seeing what is on the market in few months makes sense to me.
Anyway, what I would actually like to do is to create a different (but compatible) footprints for switches and having the ability to "easily" generate KicadFiles for different switches/sockets just by changing the footprint and without having to reroute everything. It has it's cons, obviously. But seems to me like pretty reasonable solution.
If you are going to be using encoders, expect to be plugging the keyboard only into the part that has your encoder. Encoder from the other half (the one that is not connected with a usb cable cable) will be skipping steps and generally be unusable for any smooth operation. There's a QMK bug report somewhere, but I can't find it now.
I do remember seeing this issue in the QMK repository too, back at the time I was working on the first version. I kind of hoped it's going to be fixed eventually and forgot about it. Anyway, I am not exactly an encoder-power user so I didn't even notice there's a problem. I assume you have verified this while testing? I am trying it right now but It seems to me that both work without skipping. But it's hard to tell with my current mapping (secondary encoder has pgup/down so it's hard to say) If that's the case I might at least mention it in the documentation.
Something I am still investigating – some key combinations just do not work. There is probably a technical reason for why that happens, but other keyboards don't have such issues. I have a suspicion that some keys need to be routed differently.
Version 1 has almost the same routing as Lilly58 apart from some changes around micro and one additional key. Version 2 is routed from scratch. But both were my daily driver for several months (I am typing on version 2 right now) and I do type and use shortcuts lot (I am not a gamer, though). So far I haven't heard similar complaints as the above. The matrix is the same for both boards (and it is the same as for Lilly58 + one key on each side). So I fail to imagine what routing problem could cause problems with some key combinations.
I would personally double check the matrix (all the diodes, orientation) and soldering. Another thing I have seen when a PCB bottom plate is used: sometimes the bottom plate gets scratched a bit by long pins from switches and those create an unwanted connection through the copper layer of the bottom plate. Happened to me with one Corne build (wasn't using sockets, though).
Anyway, if you in the end figure out what the problem was, let me know. I am curious and of course would be happy to fix it it it is fixable on the side of the desing.
AlexDaniel
DaneEvans
Hi! After having built two sofle 1 keyboards, here are two biggest things I would like to mention:
The keyboards are missing a “Ctrl”-like key. This is something I didn't understand when I was choosing a keyboard. That is, there should've been extra key on the bottom row (on the outside column). I do not use it often, because obviously with all the thumb modifiers there are just better alternatives. I'm coming from japanese laptop keyboards and the transition for me was very easy because sofle matches them pretty accurately. However, in practice, after days of using sofle, I realized that I still need that key. Moreover, some people seem to be using their palm to press that key. I understand that Sofle is a personal project that was built for personal needs of a specific person, but the takeaway here is that the intentional omission of the ctrl-like key makes sofle less suitable for many people, even if otherwise it might fit their requirements perfectly. This issue is probably even more pronounced on Sofle v2 because the bottom row is shifted even more to the center.
Sofle with normal switches is a little bit “too high”. I guess this can be solved with palm rests, and the extent of the issue highly depends on the size of the hands. However, that makes choc switches extremely desirable, and I for myself have already decided that the next keyboard I make will be using low-profile switches. There seem to be several alternatives now, all of them being incompatible… so, yes, it's a difficult topic, but the outright omission of low-profile switches on Sofle v2 means that, again, Sofle v2 is less appropriate or desirable for many people.
Here are also some other notes that are potentially useful: