Inspired by riskable’s void switch and to further push my agenda of fully 3D printed keyboards I have set out to design a 3D printed switch as well. I believe that by removing the requirment to be compatible with commercial keycaps one can simplify its design compared to the void switch. I have come up with a design I am happy with. Iterating has been challenging due to my 3D printer having frequent clogs ever since I moved it into an enclosure in the cellar.

Since I considered handwiring hall effect sensors to be challenging (e.g. to ensure relatively constant distance between sensor and magnet) I set out to design a PCB around this (my first), with the help of ergogen. The PCB is close to being ready, I have routed it and it seems fine. I am currently breadboarding the circuits to make sure I have not forgotten anything. Next I plan to put it online for external review before sending it to a PCB manufacturer.

Last task is the firmware. They is no specific firmware for hall-effect keyboards that support the RP2040, so I plan to use KMK with custom matrix scanning code for the analog multiplexer. Having recently discovered menelaus by technomancy, written in scheme and beautifully commented to be easy to follow, I have the itch to write my own (in scheme). However, apart from delaying project completion further, I could not find any scheme for the RP2040. There is uLisp which comes close but is more lispy than schemey.

Time invested: over 38 hours

When I build my latest 36 keys keyboard, I wanted to simultaneously learn a new keyboard layout. I chose the layout (quite the rabbit hole) and trained daily for 6 months. Baseline speed on QWERTZ is around 40-42 wpm. I made it to 32 wpm on the new layout. However those missing 25% really made typing on the new keyboard very sluggish. Consequently, I never switched full time. Over time and being pushed around on my desk some of the contacts on the 3D printed hotswap sockets came loose, causing some key presses not to register. So I keep typing these posts on a normal (i.e. non-split, row staggered) keyboard (a Keychron K7). I really hope to switch layout in the future. Either with the new hall-effect design, or perhaps by building an existing design (looking at the Cheapino).

Time invested: over 12 hours.

Inspired by a post on how to read MP3 id3 tags in Erlang, I had the idea to create a domain-specific language in scheme for such a purpose. The code is almost complete. I still want to include 2 features and have a strong test coverage and good documentation. The last two are the probably the main reasons for the delay in getting this out the door. The project has a cool name and I even designed a logo for it! I learned a tremendous amount about scheme macros through this project and I am really proud of it. Which is of little use to others unless I finally publish it! After I want to write a kaitai backend for it. But that means parsing really weird YAML.

Time invested: over 35 hours

This was the project I chose to learn scheme with, first commit is probably around 2019. I have actually made this one public but never wrote about it because I had to really pare down its scope to convince myself to release it. And immediately found ways to improve it which would then make for a better post. This is a classic case of scope creep. Obviously the scope it way too large: replacing the R or python ecosystem for bioinformatics and scientific computing with scheme! It originated in my displeasure of using R and wanting something more elegant. Since I have been doing less and less bioinformatics, I am unsure where this project will go.

Time invested: over 30 hours.

I really got into coffee over the COVID times and want to bring this to a new level by roasting my own beans. However, I am too cheap to buy a commercial roaster (which are expensive!). So I turned to DIY. Initially I wanted to build a fluid bed roaster. However, the pump I bought is too weak to levitate any reasonable amount of beans. So I am turning this into a drum roaster. It can be controlled by Artisan over WiFi (for me that was the easy part). There are still some electrical issues (I believe I may be switching the neutral wire depending on the orientation of the plug) and practical ones: do I have enough heat for the amount of beans I want? How to make the drum turn? I hope to pick this back up as the weather gets milder (I can only roast outside and do not want the outside temperature to be so low as to influence the results).

Time invested: over 13 hours

In the past, I had tagged my music using beets. True to the datalake concept I did not write the final tags to the mp3 files but kept them as separate metadata in the beets database. To then play it, I found a script to convert the beets database to an mpd database and used that for a while to play the media. Combined with snapcast, that became a multi-room audio solution. Combining it again with raspotify to also stream Spotify into the multi-room audio setup created issues with the timing (the stream played too fast) that I could never fix. I then discovered LMS which works flawlessly as multi-room audio solution. But it would not read the beets database. My first idea was to try to convert one DB schema into the other. Then I found beetfs, an abandoned project which exposes the beets database as a FUSE file system. This genius idea de-couples beets from the actual software to read the music files. I have since re-implemented beetfs (at least the parts I need for my purpose). Where I am stuck is that I want to export the FUSE filesystem via SAMBA. For reason I cannot yet explain, it does not work. SAMBA does not show the FUSE mountpoint! Maybe my implementation is missing some crucial system calls? Resolving this is blocking me publishing it, as it may point towards bugs/flaws in the software. Also it blocks me publishing the damright chapter on music where it would take a main role.

Time invested: over 10 hours

It is quite obvious, that I have too many hobbies/pet projects. Focussing on a smaller subset would allow me to complete more of them and more regularly. Here is the nice thing about hobbies though: they do not really need a justification. Most projects for me are exploration on aspects of technology that fascinate me. I learn a lot doing them and they often provide motivation when the rest of my life does not. As you can imagine, my list of project ideas is much longer.