Building Groovie, an Advanced Web-Based Drum Machine / Beat Sequencer

Groovie sits in a lineage the author traces back to a 2012 JavaScript app that predated the Web Audio API and used the now-deprecated Mozilla Audio Data API. The progression from that toy, to NoiseCraft, to Groovie is essentially a story about UI and data-model constraints: each iteration added capability, but NoiseCraft forced users to encode an entire song as one long pattern, which the author found tedious. Groovie's design choice, separate patterns plus a timeline that sequences them over time, is the structural answer to that complaint, and it is what makes the project interesting beyond another web drum machine.

The genuinely load-bearing engineering problem here is the URL fragment budget. The author is targeting ~1,800 characters so links survive being pasted into chat clients and social posts, which works out to roughly 10,800 bits at 6 bits per base64url character. A naive bitmap for one 32-sample, 64-step pattern already consumes about 2,048 bits, and that is before sample indices (9 bits each, supporting up to 512 samples), per-step volume, panning, effect sends, and a multi-row timeline bitmap. The author alludes to compression tricks to fit 32 patterns plus timeline into the budget; the specifics are partly in the source article and partly in the open-source code, but the framing is that bitmaps over sparse, structured grids compress well, which is the kind of insight worth borrowing for other client-side stateful apps.

For a working engineer, the practical takeaway is methodological rather than product-level: this is not a service to integrate but a reference implementation of a particular approach to shareable, backend-free state. The version-number nibble in the encoding is the most underappreciated detail, it means a future Groovie can ship breaking changes to its encoding without invalidating links already in the wild, which is a problem many client-side apps with serialized state never solve at all. If you are building anything that puts app state into URLs (demos, shareable visualizations, design tools), the encoding scheme here is a worth studying, and the open-source license makes it directly reusable.

Where the design stops working is exactly where the budget stops working. Once a project's encoded state approaches or exceeds ~1,800 characters, the shareable-link model breaks down and the app presumably falls back to some other mechanism, the source article is cut off before that discussion, but it is the natural ceiling on the approach. The polyrhythm feature also has a real-time cost: the scheduler has to track multiple patterns at independent step counts simultaneously and advance them in a way that stays sample-accurate, which is non-trivial in the Web Audio API and is the kind of thing that tends to drift on slower devices or under main-thread pressure. Finally, 'free forever' with no paid tier is a sustainability posture, not a technical one, and the single-feed signal here means the project's longevity is more an open question than a settled fact.