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

Pointers Gone Wild

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

August 6th, 2026

This is a blog post about a new music app called Groovie that I put together over the last few weeks. All the way back in 2012, I built MusicToy, one of the earliest JavaScript music apps on the web. This is a very simple sequencer that uses a pentatonic scale and a few samples. It's designed to be very intuitive for beginners. The reason I say one of the earliest is that this app actually predates the Web Audio API. The first version used the now long-deprecated Mozilla Audio Data API. What's interesting about it though is that MusicToy allows you to share songs without using any kind of backend. It's a fully static website, but it can encode patterns into the hash/fragment part of the URL (a cool, still underrated web trick).

Since then, I've created several more advanced web-based music apps, the most advanced one being NoiseCraft. NoiseCraft has sequencer nodes with multiple selectable patterns. However, it's extremely tedious to build a song from a single long pattern. Something that I've felt was lacking is a way to chain multiple patterns together, in part because it wasn't clear to me back then how to do that cleanly in terms of user interface design. With this project, I wanted to finally tackle that problem.

Groovie is a drum/beat sequencer app that uses samples and has a number of advanced features. I built it because I saw kind of a gap in the market. There are many drum machines out there on the web, but most of them are very basic with a fixed drum kit and a single pattern. Some of them are more advanced, but they're often ad-ridden or require a paid account. The few more advanced ones that don't have those issues often have confusing user interfaces. Groovie has 150+ samples to select from, up to 32 patterns, and a timeline view that allows sequencing multiple patterns over time, and playing multiple patterns at the same time. The patterns can have variable lengths and create polyrhythms. It also has a low-pass/high-pass filter, delay, and per-sample volume and panning, among other features. It does all of this while maintaining a pretty intuitive UI with a responsive layout that's still usable even on a mobile phone, and best of all, it's open source, and free forever.

Here are some example pieces/beats:

Berlin-techno arrangement

Drill and bass arrangement

House groove panned wide

Rock music arrangement

The classic Amen Break

A drum and bass beat

Like MusicToy, Groovie is fully static and encodes patterns and projects directly into the fragment part of URLs. However, it's packing a lot more information into that space, with projects that can have up to 32 patterns, selectable samples, and a timeline that can span thousands of steps. As such, I made a genuine effort to be clever with the way this information is encoded. I wanted to target a total link length limit of 2000 chars to keep links shareable on social media platforms and messaging services, or a budget of about 1800 characters for the fragment part. Using a base64url encoding, that leaves us 6 bits of information per character, or 10,800 bits in total. I find that encouraging, because I know from experience that you can actually encode a lot of information in that many bits.

Anatomy of a Groovie link: static host, readable song title, project data packed into the fragment

The song title is encoded in a format that's still human-readable for convenience, with spaces replaced by underscores, and markdown characters intentionally excluded to avoid potential formatting errors when links are included in markdown documents. Groovie's encoding uses 4 bits to write a version number, which means there's room for incrementing this number to add new features or encoding improvements to Groovie without breaking older shared links.

A pattern with one row per sample, and say 16 steps in length, is mostly just a grid, which can be naively encoded as a bitmap. I say naively because if you have 32 samples and 64 steps in length, that's already 2048 bits, meaning we bust the 10,800 bit budget with only a handful of patterns and no other data. We also need to encode the index of the samples for each row, which at the moment I'm using 9 bits for, allowing for up to 512 samples. Then each row can also have stereo panning, volume and effect send settings, which also take a few bits each to encode. The timeline itself can also be essentially represented as a bitmap, with one row per pattern, and one bit for each position where a pattern could be playing or not. Groovie uses a few clever tricks to try to encode this information using far fewer bits than a raw bitmap.

A pattern is a grid of on/off steps, which can be naively represented as a bitmap

When trying to optimize something, I think it's very helpful to have a set of benchmarks to give you useful metrics....