veikman / dactyl-keyboard Goto Github PK

The original dactyl used a TRRS connector instead of RJ-9. It would be nice to have support for choosing either a circular aperture or a rectangular one for the board-to-board connector so that a TRRS jack would still be possible.

To paraphrase something I wrote in #17:

The most beginner-friendly substantial programming contribution to the DMOTE project I can think of at the moment is to restore support for the Dactyl-ManuForm’s MCU shelf. Have a look at https://github.com/veikman/dactyl-keyboard/blob/master/config/dactyl_manuform/base.yaml: It’s listed as the first missing feature for upstream parity. It’s the thing that holds the microcontroller PCBA inside the case.

This task would consist of:

• Creating a third configuration option for the MCU support style setting documented here (notice documentation is auto-generated; you would be editing dactyl_keyboard/param/main.clj and schema.clj).
• Grabbing Tom Short’s model code for the shelf out of the upstream (the parent project).
• Finding a logical place for the code in DMOTE’s modularized package structure. As of v0.5.0 the model code itself would go into auxf.clj, but in DMOTE, it is also necessary to react to the user’s configuration to decide which style of support to build (see core.clj) and where to put the model in relation to some other feature selected by the user.
• Revising the Dactyl-ManuForm YAML configuration file to use the new style, and striking that item off the list of missing features in the same file.
• Integrating it all so that the shelf ends up in the right place on the Dactyl-ManuForm and is also reasonably easy to use with novel designs.
• Testing the result by importing a genuine Dactyl-Manuform from Tom’s STL into the scene with your own DMOTE Dactyl-Manuform build (by editing the SCAD file), to see that the shelf does indeed match the original. Also testing to see that other build targets with other MCU support styles are not broken (regression testing).
• Regenerating the built-in settings documentation so it mentions the new style.
• Updating the change log.
• Submitting a pull request.

This could end up being a useful tour of the project’s different parts, without having to design really new stuff.

Hi,

Just figured this out while trying to play a little bit with DMOTE on my most powerful workstation which runs Windows. One of the source file in this repository is called aux.cij, however as "AUX" is a preserved file name Windows inherited from the MS-DOS era, the result is that this file cannot be created when Git is trying to clone this repository on Windows.

While I think the author probably does not really use Windows, I would really appreciate if anyone can make the project more inclusive to Windows users by renaming the file (and probably the associated namespace) on another OS.

Thanks.

nub Q: Will this article help me?: https://adereth.github.io/blog/2014/04/09/3d-printing-with-clojure/

I haven't found any other way to contact

Hi Viktor, thank you for your amazing work! This is not an issue.
I'm a happy owner of DMOTE, but I can no longer stand the wires and thanks to recent advancements in NRF+ProMicro community-designed circuits (https://github.com/joric/nrfmicro/releases/tag/1.3), I decided it would be shame to not use this as an opportunity to build myself another keyboard, but I can't decide which one to build.

My questions:

1. have you ever printed dactyl manuform? if yes what's your opinion on it when compared with your work? I'm mainly interested in differences in how thumb keys are laid out. In DMOTE 3/7 keys seem to be hard to reach for me (mainly the middle one, the one behind it (looking from hand's perspective) and the one below them). On the other side, I feel like my thumb will be doing this on DManuform. Sorry for asking this non technical question - unfortunately, I didn't find any answers to that question online.
2. can you maybe point me a direction where in your config I could try to

• adjust the angles of thumb cluster and it's placement relative to the rest of the case? I'd like to try:

  • rotate it towards ground, and in opposite direction
  • move it closer/away from the hand (west/east axis)
  • rotate it towards/outwards to the hand

• minimize the case:

  • remove back wall (EDIT: cut down/slim down; just realized removal would suggest a hole in the case...)
  • reduce/slim down amount of material connecting the case and cluster from the 'inside of the hand' (nearby south middle) - I'm ok with how challenging it will be to solder it

To some extent I got familiar with your config, I almost removed the back wall, but I always ended up with some artifacts like holes in case of hanging material.
Are these modifications possible to do from config, or do I have to dive into the code? (which is something I want to avoid since I'm not familiar with closure and it's ecosystem)

Hi Viktor,

Not so much an issue, but I'm building a DMOTE keyboard (from the default config) and I'm wondering how you handle numerical keys? I notice in your demo you seem to handle them fine, but I can't see any pictures of how that works. Obviously It's something that can be customised, but I'm curious to know what has worked well for you.

Cheers.

Hi!

It seems like none of the images in the build guide for Concertina v0.7.0 works, I've tried in multiple browsers on multiple devices.

What are the advantages to using threaded_caseside.yaml over threaded_mutual.yaml. Also, is there a reason the wrist rest is by default at an angle to the keyboard, is it more ergonomic?

I was getting this error running lein run with the default setup:

Exception in thread "main" java.lang.IllegalArgumentException: Must hint overloaded method: toArray, compiling:(flatland/ordered/set.clj:12:1)

The issue is pending here and until it is fixed I switched the dependency to this fork.

Hey, I'm really interested in printing and trying out the concertina config you're building, but it seems to be worked on currently. what would you say would be a good way to get started with this?

Hi Viktor
You made a great work expanding @adereth and @tshort work and making this project as customizable as possible to the point that any keyboard can be built with it.
I think the next step should be declaring this project as such.

After gaining some experience with it I think that "getting started" is really hard. The workflow and syntax aren't intuitive and the docs need expanding, additionally, more examples (like this #15) could really be helpful understanding the basics.

Hi,

Before printing I spent time reading through the docs and the configs, but it seems that maybe I missed something. The cherry switches don't seem to fit the holes. The 'height' of the holes is not quite enough on the final product. Did I PEBKAC this (i.e didn't RTFM well enough) or is it potentially a printing issue?

Cheers

I realize the STLs are out of date (i generated some updated cases and plates myself).

However, for those who wish to use the existing STL files to print a keyboard, they can use this pre-built STL file. (Mirror it in your 3d printer slicer to have one of each side). It's 2.4mm thick, with chamfered screw holes.

old-right-5x6-plate.stl.zip

I cannot build for some reason. At current master 5000547

The original tshort/dactyl keyboard builds fine.

dmote-keyboard> lein run
Could not find artifact scad-tarmi:scad-tarmi:jar:0.2.0-SNAPSHOT in clojars (https://repo.clojars.org/)
This could be due to a typo in :dependencies, file system permissions, or network issues.
If you are behind a proxy, try setting the 'http_proxy' environment variable.

Hi, first off sorry if this is the wrong place to ask this.

I have been following this repo for a while, as it looks like the closest thing to my dream keyboard as possible (though I think a little screen showing what layer or profile your on would be cool). I have never built a keyboard before, so I'm unsure what I would need to buy to get started on this. I live in Guatemala so not much is available here, but in about two weeks I have a way to get stuff from the U.S.A. I do have an Ender 3, so I should be able to print the case. I just don't want to pick up the wrong stuff, as I won't be able to return it and replacing it would be challenging.

I was wondering if I could get some help in what I need bare minimum to get this project started.

Switches:
I know I need switches and I'm curious if any "MX style" switch will work, like for example Drop Halo Cherry-Style or would I need actual Cherry MX's like MX Browns.

If I get the clear ones, that means I could have a few LEDs inside the keyboard and it would shine through so I can see the edges of the keycaps right?

Diodes:
Is this what I need between the columns or rows when wiring? 1N4148

Keycaps:
Do I need any special type of keycap? Or could I say buy a cheap kit like this Replacement Keycaps and use all the small ones from it? Also I'm assuming a double shot keycap means that with some LEDs in the keyboard you could see the legends lite up?

Micro-controller:
From my understanding I need two, on for each half of the keyboard. Are there any you would suggest for a first time build? Like a Teensy++ 2.0 or is something smaller like a Teensy 2.0 better, or go for the 3.2? I would like to add some LED's for back-lighting as mentioned above so I don't know if that affects this choice.

LEDs:
What would I need for LED's for say the indicator, and the back-lighting, is it possible to use RGB ones where say the back-lighing changes per profile/layer?

Sorry to bomb you guys with so many questions. Thanks for this awesome project and any help you can give.

Disclaimer: I have yet to build a concertina.

I've started using a vertical mouse; it's great, but the transition from using a keyboard to using a mouse requires lifting my hand over the mouse, often knocking it over. With a split keyboard, there would be the option of putting the mouse in the middle, but with a vertical version, like the concertina, this just recreates the same problem. It seems to me that the answer is probably to embed a trackball in the concertina. I wondered if you had considered that or if you had any thoughts about trying it.

Hey, I still do not have the skill to do it myself but for all these months one of my wants is to use single-switch pcb's for the modular benefits. Main thread:
https://deskthority.net/viewtopic.php?f=7&t=11420&start=

Some sell 30 pieces for 5$ which is nice investment at least for not dirtying/damaging the switches with solder
https://keeb.io/products/amoeba-single-switch-pcbs=

Have you seen these? What are your thoughts?

Hi, original dactyl keyboard is licensed under CC BY-SA now.
adereth#29

But DMOTE is under CC BY-NC-SA.
Would you change this?

Note:
tshort#17

I was helping someone out with making their own DMOTE keyboard, and they were struggling with the proper order to wire things together. I looked at how the layout is defined in the QMK firmware and drew an image for how it seems the keys should be connected.

Is my drawing correct?

Do you want me to submit a PR that includes this, or an updated, image?

Dear Mr Veikman,
i like your keybard concertina design and i want to build one.
Where do buy or get the ALPS-style switches? That is a big riddle for me.
Best regards,
Siegmar

What keycap profile do you use?

The random set I have at hand seems a bit tight.

Hey man, I continue learning Clojure with your project in the background. I also have my Ender 3 Pro 3d printer. It might take me a while to get to the level to make the changes I have in mind so I decided to address one of them (fasteners) beforehand. Maybe you will like the idea.

Some users have trouble making adjustments to print small circles on the printer bed.

• Making the fastener outer wall shape square may help with the printing process.

Using solid plastic for the screw holes may result in cracks in the case, especially if the walls are thin.

• Making fastener walls bigger allows using 30% infill. So the screw can "dig in" to the plastic without risking unintended cracks. It should help with the stiffness in a way too.
• Alternatively, on top of the fastener object if it's nice and fat and square you can add a hexagonal hole for a hexagonal nut. For the durability and some additional weight.

Offtop:

• How do you feel about the case stiffness (when pressing it from the top) and weight?

I have cloned and unicode-made and installed it with lein install,
afterward I cloned dactyl-keyboard and ran the makefile.

the following error occurred after this command java -jar target/dmote.jar:

my knowledge in Clojure is limited and I believe I did something wrong, but i can't really tell what.

WARNING: boolean? already refers to: #'clojure.core/boolean? in namespace: clojure.tools.analyzer.utils, being replaced by: #'clojure.tools.analyzer.utils/boolean?
WARNING: boolean? already refers to: #'clojure.core/boolean? in namespace: clojure.tools.analyzer, being replaced by: #'clojure.tools.analyzer.utils/boolean?
Exception in thread "main" java.lang.NoClassDefFoundError: unicode_math/core$⌈ (wrong name: unicode_math/core$∈), compiling:(/tmp/form-init9098805308791983335.clj:1:73)
	at clojure.lang.Compiler.load(Compiler.java:7526)
	at clojure.lang.Compiler.loadFile(Compiler.java:7452)
	at clojure.main$load_script.invokeStatic(main.clj:278)
	at clojure.main$init_opt.invokeStatic(main.clj:280)
	at clojure.main$init_opt.invoke(main.clj:280)
	at clojure.main$initialize.invokeStatic(main.clj:311)
	at clojure.main$null_opt.invokeStatic(main.clj:345)
	at clojure.main$null_opt.invoke(main.clj:342)
	at clojure.main$main.invokeStatic(main.clj:424)
	at clojure.main$main.doInvoke(main.clj:387)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.lang.Var.applyTo(Var.java:702)
	at clojure.main.main(main.java:37)
Caused by: java.lang.NoClassDefFoundError: unicode_math/core$⌈ (wrong name: unicode_math/core$∈)
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:74)

I'm trying to generate an SCAD file without the aux keys and the mounting plate, but deleting the aux0 sections from dmote/base.yaml make the compilation fail with ExceptionInfo Configuration lacks key clojure.core/ex-info (core.clj:4739)

The scad-app link in the README.md is https://github.com/veikman/scap-app instead of the correct https://github.com/veikman/scad-app

I'm on MacOS with these installed via homebrew:

• Clojure CLI version 1.10.3.998
• Leiningen 2.9.7 on Java 17.0.1 OpenJDK 64-Bit Server VM

I get the following exception when I start following through the tutorial:

$ lein run
Exception in thread "main" java.lang.ArithmeticException: Divide by zero, compiling:(/private/var/folders/rd/wv69_b9162zd60yfpdxb3kpm0000gn/T/form-init773116273006867215.clj:1:124)
	at clojure.lang.Compiler.load(Compiler.java:7526)
	at clojure.lang.Compiler.loadFile(Compiler.java:7452)
	at clojure.main$load_script.invokeStatic(main.clj:278)
	at clojure.main$init_opt.invokeStatic(main.clj:280)
	at clojure.main$init_opt.invoke(main.clj:280)
	at clojure.main$initialize.invokeStatic(main.clj:311)
	at clojure.main$null_opt.invokeStatic(main.clj:345)
	at clojure.main$null_opt.invoke(main.clj:342)
	at clojure.main$main.invokeStatic(main.clj:424)
	at clojure.main$main.doInvoke(main.clj:387)
	at clojure.lang.RestFn.applyTo(RestFn.java:137)
	at clojure.lang.Var.applyTo(Var.java:702)
	at clojure.main.main(main.java:37)
Caused by: java.lang.ArithmeticException: Divide by zero
	at clojure.lang.Numbers.divide(Numbers.java:163)
	at scad_tarmi.dfm$ratio.invokeStatic(dfm.clj:40)
	at scad_tarmi.dfm$ratio.invoke(dfm.clj:40)
	at scad_tarmi.dfm$error_fn$compensator__4233.doInvoke(dfm.clj:62)
	at clojure.lang.RestFn.invoke(RestFn.java:425)
	at scad_tarmi.dfm$error_fn$compensator__4233.invoke(dfm.clj:55)
	at dactyl_keyboard.cad.key.switch$cap_channel_negative$step__1713.invoke(switch.clj:52)
	at dactyl_keyboard.cad.key.switch$cap_channel_negative.invokeStatic(switch.clj:68)
	at dactyl_keyboard.cad.key.switch$cap_channel_negative.invoke(switch.clj:46)
	at dactyl_keyboard.cad.key$cluster_channels$modeller__2299.invoke(key.clj:285)
	at dactyl_keyboard.cad.key$cluster_channels$fn__2303.invoke(key.clj:290)
	at clojure.core$map$fn__5587.invoke(core.clj:2745)
	at clojure.lang.LazySeq.sval(LazySeq.java:40)
	at clojure.lang.LazySeq.seq(LazySeq.java:49)
	at clojure.lang.RT.seq(RT.java:528)
	at clojure.core$seq__5124.invokeStatic(core.clj:137)
	at clojure.core$apply.invokeStatic(core.clj:652)
	at clojure.core$apply.invoke(core.clj:652)
	at dactyl_keyboard.cad.key$cluster_channels.invokeStatic(key.clj:289)
	at dactyl_keyboard.cad.key$cluster_channels.invoke(key.clj:282)
	at dactyl_keyboard.cad.key$metacluster$fn__2311.invoke(key.clj:302)
	at clojure.core$map$fn__5587.invoke(core.clj:2747)
	at clojure.lang.LazySeq.sval(LazySeq.java:40)
	at clojure.lang.LazySeq.seq(LazySeq.java:49)
	at clojure.lang.RT.seq(RT.java:528)
	at clojure.core$seq__5124.invokeStatic(core.clj:137)
	at clojure.core$apply.invokeStatic(core.clj:652)
	at clojure.core$apply.invoke(core.clj:652)
	at dactyl_keyboard.cad.key$metacluster.invokeStatic(key.clj:302)
	at dactyl_keyboard.cad.key$metacluster.invoke(key.clj:299)
	at dactyl_keyboard.cad.body.assembly$main_body_right.invokeStatic(assembly.clj:215)
	at dactyl_keyboard.cad.body.assembly$main_body_right.invoke(assembly.clj:205)
	at dactyl_keyboard.core$finalize_asset.invokeStatic(core.clj:298)
	at dactyl_keyboard.core$finalize_asset.invoke(core.clj:286)
	at clojure.core$partial$fn__5563.invoke(core.clj:2624)
	at clojure.core$partial$fn__5561.invoke(core.clj:2616)
	at clojure.core$map$fn__5587.invoke(core.clj:2745)
	at clojure.lang.LazySeq.sval(LazySeq.java:40)
	at clojure.lang.LazySeq.seq(LazySeq.java:49)
	at clojure.lang.RT.seq(RT.java:528)
	at clojure.core$seq__5124.invokeStatic(core.clj:137)
	at clojure.core$apply.invokeStatic(core.clj:652)
	at clojure.core$mapcat.invokeStatic(core.clj:2775)
	at clojure.core$mapcat.doInvoke(core.clj:2775)
	at clojure.lang.RestFn.invoke(RestFn.java:423)
	at scad_app.core$refine_all.invokeStatic(core.clj:265)
	at scad_app.core$refine_all.invoke(core.clj:260)
	at dactyl_keyboard.core$builtin_assets.invokeStatic(core.clj:306)
	at dactyl_keyboard.core$builtin_assets.invoke(core.clj:303)
	at dactyl_keyboard.core$run.invokeStatic(core.clj:360)
	at dactyl_keyboard.core$run.invoke(core.clj:355)
	at dactyl_keyboard.core$execute_mode.invokeStatic(core.clj:389)
	at dactyl_keyboard.core$execute_mode.invoke(core.clj:378)
	at dactyl_keyboard.core$_main.invokeStatic(core.clj:412)
	at dactyl_keyboard.core$_main.doInvoke(core.clj:408)
	at clojure.lang.RestFn.invoke(RestFn.java:397)
	at clojure.lang.Var.invoke(Var.java:377)
	at user$eval149.invokeStatic(form-init773116273006867215.clj:1)
	at user$eval149.invoke(form-init773116273006867215.clj:1)
	at clojure.lang.Compiler.eval(Compiler.java:7062)
	at clojure.lang.Compiler.eval(Compiler.java:7052)
	at clojure.lang.Compiler.load(Compiler.java:7514)
	... 12 more

It only succeeds when I jump to the step where I run lein run -c config/base.yaml -c butty.yaml

Trying to build lein run -c config/dactyl_manuform/base.yaml also fails with this exception.

This happens on the latest commit (651532c) as well as the dmote-v0.7.0 tag. I tried going to even earlier tags but started getting dependency errors.

I've been building a DMOTE, and after I put on the key caps I discovered that a few of the key caps interfere with each other when pressed. I've used DSA keys from https://pimpmykeyboard.com/, which I think match the expected key cap form factor.

Delta between default (Makefile):

-dmote_62key: target/dmote.jar dmote/base.yaml
+dmote_62key: target/dmote.jar dmote/base.yaml dmote/mx.yaml

Upon reflection you can actually see some of the cross column collisions in the visualization render (top inner keys):

However, some of the interference is more noticeable after putting key caps on and pressing keys.

This affects the inner most column (all three keys) and the top two keys of the two adjacent columns. I've also noticed a small amount of cross-column interference on the same keys.

I feel like I missed something, because of the amount of overlap that I ended up with. Any suggestions / changes for avoiding this for others?

My personal solution will be to double check 3d-print residue, and the file down keycaps as necessary. Although I understand filing down key caps is probably not a desirable solution for others.

I'm trying to adapt mx.yaml to support Kailh switches. I've added key-mount-thickness: 1.4 which makes the switch slot thin enough for the switches' built-in clips to work. However, I couldn't find how to shrink or get rid of the mx nubs in the side of the switch slots. How does one adjust the nubs?

I wish to make the north of the DMOTE more like the dactyl manuform, i.e. being a lot smaller and having a connector hole in the bottom north west. To make the north end smaller, I disabled the rear-housing and the reflection-port by setting include: false for both however, I can not work out how to then add a wall on the north side.
Thanks