Sample library, local-first

Finding a sound in a cloud library is: type a word, wait, click a result, wait for it to stream, decide no, repeat. Each wait is two or three seconds, which is nothing, and thirty of them is the difference between following an idea and losing it.

This is not really a tooling complaint. Writing music depends on a loop between hearing something and reacting to it, and that loop has a speed below which it stops feeling like playing and starts feeling like filing. Every wait is a chance for the thing you were chasing to go quiet.

The first half signs into the account I pay for and pulls the library it already entitles me to down to disk, organised by pack, skipping anything already present so it can be re-run at any time. Metadata goes into a small database as it goes.

The second half is a local single-page app pointed at that database. It searches as I type, plays instantly, and drags files directly into the DAW. No network in the loop at all.

The part I would keep in anything like this is the ceilings. A bulk downloader with no limits is how you wake up to a full disk, so it stops cleanly when either a total-size or a file-count budget would be exceeded. A tool that runs unattended against something as open-ended as “everything” needs to know how to give up, and deciding that in advance is much easier than deciding it at two in the morning.

The general version: when a tool sits inside a fast feedback loop — creative work, debugging, anything with an audition step — latency is not a performance metric, it is a change in what the tool is for. Below a certain speed you explore. Above it you plan, and planning is a different and worse activity for finding a sound.

Which usually means the fix is not optimisation but removing the network from the inner loop and paying the cost once, up front, at a moment when waiting does not matter.