DEV Community

Cover image for I Built the Sampling Workflow I Wanted for My SP-404
Ruben
Ruben

Posted on

I Built the Sampling Workflow I Wanted for My SP-404

Music has been part of my life since I was a kid. Tinkering with instruments, playing shows with my rap group, then moving into beat production, instrumentals, lo-fi, that kind of thing. That's a story for another day.

What's relevant here is the SP-404, a sampler I've been having a lot of fun with. The problem is that the sampling workflow is pretty tedious, and since Leo arrived, free time has become even scarcer. Of course, I'm not trying to be the next J Dilla; I just want to have a good time.

Even if you do not care about samplers, this is the part that may still be useful: personal tools are allowed to be narrow. Sometimes the right product decision is not to make the workflow more general, but to remove exactly the friction that keeps you from doing the thing you already wanted to do.

The craft workflow

The original process is for dedicated music nerds. It starts at a record store, digging through old vinyl to find ten seconds of sample to build a track around. Once you have the record, you locate the sound that caught your attention, connect the turntable directly to the machine and record it, then chop it into smaller pieces and assign them to the pads to play with.

It has its charm. But when you have a baby at home and you want to get some composing done between a diaper change and a walk, the process is just too long.

The digital workflow isn't much better

The digital version of the same problem isn't a big improvement. You find a track you like, download it, convert it to the format your machine accepts, trim the specific section you want to sample, rename the file following whatever naming convention your device expects, and copy it to the SD card. If you want multiple samples from the same track, you repeat every step. If you want to mix samples from different songs, you end up with files scattered across three folders and a couple of apps open at the same time.

Still tedious. And when you have forty minutes while Leo is at the park, that time matters.

The idea

What I needed was a shorter path: pick a song from my local library or from Freesound, select the parts I want, chop them into samples, and export a pack ready for the machine, with files already named and organized. No manual steps, no scattered folders.

That's where SampleByte came from. The interface lays out three clear steps:

  • Import audio: from your local library or directly from Freesound using their free API.
  • Extract samples: select the parts of the song you want to work with.
  • Build a pack: group the samples into sets of up to 16 pads and export for your machine.

The app includes hardware profiles for the most common devices: SP-404 MkII, Maschine MK3, MPC, and a generic WAV profile for anything else. Each profile knows what format, naming convention, and folder structure the target device expects, so the pack comes out ready to drop in.

Everything also gets saved in the app. There's a Browse tab where you can search and filter everything you've ever sampled by BPM, key, or tag. Over time it becomes a personal library you can pull from without going back to the source.

Under the hood

The app is built with Electron. On the frontend, React alongside WaveSurfer for sample editing, and ffmpeg and the Web Audio API for audio handling. Data persistence is SQLite.

There were a few days of intense back-and-forth with Claude Code to figure out the right solutions without turning this into another DAW. That meant spending real time on the product side first, generating a set of documents to nail down the scope before writing any code. What to include, what to leave out, how the workflow should feel.

Once the product direction was clear, which took more than a couple of Leo's naps and at least one night where he decided 3am was a fine time to be awake, I handed the implementation off to Codex. To parallelize as much as possible, we set up multiple worktrees, each taking one item from the plan along with its PRD and implementing the solution. The agent handled the initial scaffolding, audio library integrations, edge cases in the export logic, and most of the technical documentation.

What I didn't hand off was judgment. What flow makes sense for someone producing on hardware, what to do when a sample is too short to be useful, how to name the pads so they're recognizable when you're looking at them on the machine. Those decisions I made myself, testing the app directly with the SP-404 on the table.

I also had to go through several iterations with the agent on the UI, because the early versions weren't close to what I had in mind. That's the key difference with a personal project: I'm the main user, I know the workflow firsthand, and I have a clear opinion on how every step should feel. That level of specificity is only possible when you're building something for yourself, and it's exactly what makes the tool actually work for the workflow it was designed for.

QA I do mostly by hand: use the app, see if what comes out is what you expected. In the end, taste and intuition are still things agents haven't figured out at the human level, at least for now.

Built During a Nap

I was sketching out an auto-chop system, something that could detect silences and other audio cues to split a sample automatically. I handed the research and first implementation off to the agent, letting it look at how similar tools handle it. When I came back, the logic worked but the results were rough: it was picking up too many transients, filling the pack with small fragments that weren't really useful as samples. I had to go back in and tune the detection to get fewer hits but more interesting ones.

A niche tool, and that's fine

SampleByte is a small tool, built for a very specific workflow. It's not trying to be a DAW or compete with anything. That was the limit I set from the start, and I'm glad I kept it, because every time a conversation with Claude opened the door to adding something else, the answer was always the same: something else already does that better than we would.

Being open source doesn't change that philosophy, but it does add another layer of meaning. If there's someone out there with a SP-404 and the same frustration with the workflow, they can use it directly or fork it and adapt it to their needs. Niche tools have that going for them: they don't need to be big to be complete. Pre-built installers for macOS and Windows are on the releases page if you want to try it without building from source.

What I didn't expect was how satisfying it would feel to use something I had built myself during a nap. Leo was asleep, I had a break I liked, I chopped it, built a pack, and had it on the machine before he woke up. That is the whole product: turning the time you have into the thing you wanted to make.

Sometimes that is enough.

Top comments (0)