hkgumbs

I’m the post author, and I use this same polyfill. I even install it with the same NPM download method I wrote about.

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’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).

https://wooting.io/

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:

https://typebeat.kofi.sexy

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:

https://youtube.com/watch?v=RT0qUB4gbas

I'd highly recommend "The Beam Book" by Erik Stenman: https://blog.stenmans.org/theBeamBook/

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

Fair enough, updated.

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!

[0]: https://news.ycombinator.com/item?id=23275080

[1]: https://github.com/hkgumbs/multi/releases/tag/v2.0.0

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.

[0]: https://8thlight.com/blog/kofi-gumbs/2017/05/02/core-erlang....

[1]: https://github.com/hkgumbs/codec-beam

Thanks, these are nice clean ups! I added a note in the blog post that points to your Swizzler example. The final version of Multi didn't end up needing that NSBundle monkey-patch though since it was a "proper app" with an Info.plist file.

I built a few Swift CLIs before, but this was my first time working with AppKit (the macOS GUI framework)

Yup, that was exactly my workflow as well! And for building CLIs it's quite nice. Once I started using AppKit though, it felt like I kept running into things that weren't quite finished.

Thanks! Honestly my reasoning for avoiding XCode is fairly thin—I just hadn't used it before and didn't have it installed when I started. I imagine if I took the time to learn it, it would be fine. But I do also feel a bit weird about how developing for certain platforms requires you to use a specific IDE. I thought that was part of the goal of Swift (vs ObjC), but I may be just reflecting my own biases :)

I'm founding Trainer Vision with my partner, who is a certified personal trainer. Normally they write our blog posts since that's our target demographic. This week we switched things up and I wrote a more explanatory post. I think focusing on what your users do with most of their time is a helpful frame for any developer or creator.

Happy to answer any questions or discuss any feedback!

Thanks for the kind words, and it's fun to hear that you're local! I think I should have clarified more about my view of an assembly compiler:

A "bespoke backend, going to assembly directly" does not preclude the option of integrating with an Erlang/Elixir project. In fact, I think that you could do so via ports or NIFs in such a way that the caller wouldn't know the difference. I think of the Erlang JSON libarary, jiffy. It's largely implemented in C for performance, but the language it's written in doesn't seem to matter in practice. As long as there is an easy way to integrate it into your Erlang/Elixir project.

I think an "Elm on the server" solution would work much the same way. Focused on making a clean integration point—then choose whatever implementation leads to the most performant and reliable artifact.

Funny that you mention that—the color surprised me as well! I used https://asciinema.org/ to record, which captures ANSII escape sequences. I'm guessing there's some sort of default colorscheme applied, since I've done little to individualize my terminal.

I don't plan to do much more with this particular project. At the end of the article I mention what I believe to be a nicer direction for Elm.

Thanks for taking interest! Honestly, my "use case" is just curiosity about language implementation. I'd been hearing quite a bit of excitement around BEAM, so I wanted to explore its viability as a standalone compilation target, without relying on the existing Erlang toolchain.

If anyone using elm runs into the same dictionary-comparable issue, please understand that it's a solved problem: http://package.elm-lang.org/packages/robertjlooby/elm-generi...