What programming/technical projects have you been working on?

I just finished up my Quick Server Panels project. It lets me configure a (mobile-friendly) button-panel UI. Each button can be configured to either make an arbitrary HTTP(S) call or run a CLI command (with arguments provided by browser form) on my home server, optionally displaying/streaming the output back to the browser.

It's great for when I'm away from a computer and want to run some simple commands with my phone without having to SSH in and type precise commands on a phone keyboard.

I also use it as a universal remote - I have several HTTP-based IR emitters, and with this I can make a mobile-friendly panel of buttons whose HTTP calls tell the devices to emit IR signals for things like TV-on, volume-up, etc.

The project took way longer than I expected, because I consistently choose the harder/more "future-proof" option when given a choice (to the point of irrationality). For instance, the server has lots of safeguards for limiting which commands (and even what set of arguments) can be run. That choice, while "good" design, doesn't make a lot of sense given the threat model (the server is not meant to be internet-exposed, and operates on a trusted network by a trusted client). But I find it's more fun to build things to be needlessly extensible, and this was a hobby project after all - fun is the point!

Some other highlights:

• Lots of documentation! I tried to document all the capabilities in the README.md
• Buttons can inherit from templates with variables. This helps keep my 60-button config file readable.
• Button config properties support string expansion. Ex: https://example.com/${route}.
• CLI buttons can stream output. I use this for long-running ffmpeg jobs.
• CLI buttons can send user-configurable arguments. Ex: a CURL button lets me type in a URL to download with a simple HTML input form.

I just got a delivery notification for a bunch of electronic components. I'm going to attempt to build my first oscillator circuits so I can route them into my effect loop chain. I was a noisician years ago and have wanted to get back into it. I realized lately that I want to get more into the DIY aspect, so this should be a good starting point.

The past couple days the "UTF-8 fairy" bit me and after going to the text encoding hospital I decided I was going to spend more time learning about segmentation.

Enter Unicode Standard Annex #29. Ah yes. Number. Twenty. Nine. I need not repeat this sequence of syllables... but I will paste some links:

• https://github.com/timendum/grapheme
• https://www.bedrick.org/notes/python-icu-bindings/
• https://docs.rs/unicode-segmentation/latest/unicode_segmentation/

Some ramblings:

🤦🏻‍♂️ <-- this emoji is 17 bytes long but it is only 2 spaces wide

⸻ this is the triple em-dash. Fear no longer that AGI has stolen your sword. It is three bytes long but prints as a single character in the terminal. kinda lame

So from these examples we can see that doing len(text.encode("utf-8")) is not enough if you want to determine if something will fit on the screen.

In the terminal, emojis and certain languages have letters that show up as more than one space. In Python you can use wcwidth.wcswidth to calculate how much space something will take up. That's great.

(Although now that I know more I wonder if there are edge cases like ﷽... okay I just checked--it says it is 1 character and indeed it prints one-width in the terminal)

But if you want to ensure that a string will not print longer than one line in the terminal, your function needs to be aware of the graphemes to decide where to truncate the text. Otherwise your US flag 🇺🇸 can turn into 🇺, etc. This is because a lot of emoji and other text is built from other emoji/characters. This is not only emoji but some languages like Korean are particularly dependent on this behavior.

For text segmentation you really need to use the raw data of the UTF-8 spec to make intelligent decisions about where to cut text... but I was hesitant to add a dependency with 9 GitHub stars so I made an approximation.

While writing this up I also came across the icu library again... a familiar name but I didn't think to check that it could work here. It is an optional dependency of natsort so I'm already kind of using it... Maybe someday I'll switch to using that but for now my grapheme_iter seems to work well enough!

I finished the synthesizer portion of the software groovebox I described here. The hardest part was keeping the number of controls limited without sacrificing too much flexibility.

The sound turned out quite TB303-like but with a very distinct quality because it's all faked using phase distortion synthesis. I made the "filter" slider continuously morph from a sawtooth to a square via a sine instead of using a switch to change waveforms. The "resonance" control just mixes in a sine wave at the guesstimated resonant frequency, which is synchronized with the oscillator that provides the body of the sound and also fades to zero over the duration of a single cycle. This is probably illustrated more clearly in figures 18 and 19 of Casio's patent. One notable "improvement" on the patent is that I introduce feedback modulation of the phase, like in Yamaha's FM synths. That becomes a really nasty fuzz/distortion effect in this design.

For now it sits in my music prototyping/hacks repo is a JACK application that accepts MIDI notes and pitch bend, with simple on-screen sliders for the timbre controls. I will use MIDI messages internally for sequencer control once I build that, so it should be plug-and-play. If anyone wants to give it a go and are comfortable with JACK, the source is available here. I'm using Zig, but I haven't updated that in a while so I only know it builds with version 0.14.0-dev.2605+136c5a916.

I've been bashing together a script that uses a number of tools to accomplish a task:

1. Use Craig, the Discord bot, to record per-user time-synced audio of my weekly DnD sessions
2. Use the whisper package to convert that audio to text, and then bash it together into a time-organized transcript of the session
3. Send the Transcript to Gemini via API, with instructions to create a summary of that week's session
4. Parse that summary and send it to our DnD Discord channel via webhook

It's still very much a work in progress, but I've separately gotten all the steps to work, now I just need to combine it into one fluid step. Unfortunately there's no way for me to automate the audio coming from Craig to my Debian host, that I can see anyways, so that will have to be manual. Otherwise I can fully automate weekly AI powered recaps.

I’m currently working on a local-first, bookmarking, archive, catch all, thing. It’s an Electron app + a browser extension designed to be a single, reliable solution for saving anything I find online, since I work across a few different computers and operating systems.

The extension automatically detects what you're saving and scrapes accordingly. It can grab any image, products with their price and images, save articles in a clean reader format to read later in the app, and capture entire webpages as full-page screenshots. Everything gets saved directly to a folder on my own machine as standard markdown and image files. This means all the data is fully accessible and editable from outside of the app, no proprietary lock-in. It also means you can add notes and local files to use in the app by simply moving it to that folder. I’ve quite a lot more features planned but really want to nail the frictionless capture side of things first.

Which leads me to the main challenge I'm wrestling with now: the path to mobile access and sync. Currently I see a few options:

1. The purist approach is to remain fully local, which would mean building a native mobile app and handling sync with CRDT (ideal) or third party cloud services (easier). However, as someone with no mobile dev experience I worry this could add a chunk of time to the project, perhaps worth it though. This has led me to consider:

2. a companion web app, which would sync all the local
   files to its database periodically and be far more convenient to build and access. However this would perhaps undermine the whole "local-first" philosophy. Finally:

3. A potential middle ground is to offer a self-hosted option, which aligns with the user-sovereignty ethos while achieving the convenience of a webapp. I’m big into self hosting so this is an enticing option, but I would like to make it publicly available at some point and worry this would introduce a higher technical barrier for entry.

Curious to hear if others have faced any similar quandaries in their own projects.

I've been machine-translating all the online help for my app into other languages. I'm up to 8 languages so far.

https://akkartik.itch.io/carousel