capecodes

copy the single busybox statically linked binary into a container, and you can create a bunch of symlinks for its tools that you want to use (this is how busybox container itself works)

makes it trivial to do the dhi/rootless thing but do ad-hoc debugging and then remove the debugging tools entirely, leaving no trace/bloat behind (just one file)

base64(zstd(big state))

To Sleep in a Sea of Stars is my favorite of the last few years.

I thought Fractal Noise was meh by comparison

Oh man, then you really don’t want to know about a product I once created.

Reader could have an optional Flash plugin, and better yet, you could configure the PDF interactive plugin to dynamically download the swf file to run.

I built an entire Flex based rich UI that was dynamically loaded by the 1kb PDF you’d receive in email, the Flex app retrieved and posted data via HTTP APIs.

Because reasons.

That product was live for years. I think we shut it down as recently as 2 years ago.

To be 100% clear, wasn’t my idea.

But it was my mistake to joke about the absurd possibility to build such a thing in front of some biz folks.

Have you considered letting the user upload their own song?

I’m working on a WebMIDI based wait-for-input piano/keyboard app, like Flowkey, but bring your own music with MusicXML files.

Works amazingly well, using OpenSheetMusicDisplay lib for parsing MusicXML, rendering it to SVG (OSMD uses VexFlow under the covers) & using OSMD to map the music data into my own data model (I track everything I need for timing and visual x,y coordinates inside the SVG).

From there it’s pretty simple, just refactoring my hacky PoC I’ve been using for myself for the last year into something solid based on React + XState.

Anyways, OSMD would let you import arbitrary music as input to this, opening up the possibility of learning specific pieces