I’ve thought a lot about this! I’d love to create hardware someday that plugs directly into a keyboard and turns it into a music workstation. I recently came across the Wooting keyboard line which seems like the perfect fit, since you could get pressure sensitive keypresses (currently one big downside of the Typebeat workflow).
pressure sensitive is alright but once you move away from the absolute baseline of common hardware it's more attractive to just spend money on a real synthesizer.
go full pi appliance. it wouldn't be too hard to make an sd image, perhaps compatible with one/some of those "pi tablet" kits, that would boot straight into this, recognize various qmk-compatible usb ids and offer to push firmware.
Thanks a bunch! I wonder which gear brands you had in mind when commenting. Teenage Engineering had a big influence on how I make music, and I like to think some of their charm shines through in Typebeat.
Hi HN! I’ve been working on Typebeat for a year and a half, and I decided yesterday to make the code public. There’s also a website where you can download the macOS build and try an online demo:
The project was initially conceived as “vim for music”. All of Typebeat is controlled by the 30 main character keys on the computer keyboard. The result is a workflow that’s a little tricky to learn but fast to use once mastered. (So I suppose I nailed the vim experience in that regard.) If you’d like to see how I use it at top speed, you can check out this 2-minute jam I made recently:
Yes, pretty much. It’s definitely cool that so many folks here have left positive feedback, but ultimately I don’t have the same bandwidth and motivation that I had when I started this project. Whenever those return, I’ll return to it. Until then, I’m just planning to chew on the core idea and take in everyone’s suggestions.
I think this is a perfectly reasonable default. thanks for making something interesting and making it available for everyone to use and/or learn from.
aside: it's kind of weird to assume that all projects on GitHub are constantly being updated for free. old projects are inevitably going to outnumber new ones on any system that keeps old projects available, unless that system continues growing at an ever-increasing pace forever and ever.
A few years ago, I spent my free time building a Haskell BEAM codegen library, and that was by far the best resource I found. I noted some other projects that helped me understand things here: https://github.com/kofigumbs/codec-beam#acknowledgements
Author here—my understanding of the GPL matches that in the sibling comment. "GPL never says you cannot sell your software. It just says you have to provide source with it and you cannot prevent others from redistributing the source."
If I'm incorrectly co-opting some open source nomenclature, I'd love if someone could let me know. As I said in the issue linked above, I do need to update the purchase website to bring that language more inline with what's on GitHub.
Author here—that's pretty embarrassing, and I'm not sure how I messed that up. I do recall having to retake the Activity Monitor screenshots between drafts, so I'm going to blame my mistake on that. Adding an editorial note now!
I submitted the initial version of Multi to HN 2 months ago [0], and the response was much larger than I was expecting. Initially, I just built Multi for my personal use, so I cut quite a few corners to get something that worked. When I saw that other folks were actually trying it out, I decided to put it in the work to make the whole experience a bit nicer.
What I'm excited about most with 2.0 is that Multi is a proper macOS app itself, with a UI for creating other apps. That makes the install process much simpler (it's a normal .dmg) and streamlines future updates (install the new Multi "runtime" app and that's it—no need to update each of your generated apps manually).
There are a bunch of other improvements listed on the release page[1]. I'll keep an eye on this thread and answer any questions I can!
A few years ago, I tried to use Core Erlang as a compiler backend. It's fairly straightforward to learn even without thorough documentation. I wrote a bit about my process to try to help the next person [0]. For my particular project, I ended up abbandoning the approach and generating BEAM bytecode instead [1]. That was definitely more challenging, but it was neat to see Erlang's commitment to backwards compatibility in action. I believe that BEAM modules emitted by the first versions of Erlang are still valid on modern implementations. New functions are added and old ones are deprecated, but the actual file format version indicator hasn't changed.
