A button can play a sound. But what if holding it changes the sound? What if moving faster makes it more aggressive, or releasing it lets the energy fade away?
That is the kind of thing I wanted to make easier with AudioBits, a small open-source project for procedural sound effects on the web.
I like the idea of sound as part of the interaction. Something you can shape with the same state and events that already drive your interface. A charge building while you hold, a thruster responding to throttle, a lightsaber reacting to movement. There is a lot of room to play there, and I am excited about where this project can go.
The sound is generated in the browser
Under the hood, AudioBits uses the browser's Web Audio API. There are no prerecorded sound assets to download. The sounds are generated in real time from recipes.
A recipe describes how to build a sound: layers of tones or noise, filters that shape their character, envelopes that control how they start and fade, and effects such as delay. The engine turns that description into browser audio.
You can make a short confirmation sound or a sustained effect with parameters your application controls while it plays. For a thruster, a single throttle value between 0 and 1 can raise the motor's pitch, bring up the exhaust noise, and open a low-pass filter together. Each mapping has its own range, so the layers respond differently to the same input. Live parameters also declare smoothing, which lets the sound follow a changing value without jumping abruptly between settings.
Recipes can also describe pitch changes over time and seeded variation, so repeated effects can have some variety while keeping a way to reproduce that variation. A sound is a small system with controls you choose to expose.
The design decision here is to keep that system as structured, versioned data. A recipe can be serialized as JSON, validated before playback, saved in version control, and shared without carrying browser audio nodes or application code with it. The engine owns building and cleaning up the audio graph. Your application decides when to play and what values to send.
There is a deliberate limit to that expressiveness. Recipes describe supported audio building blocks and parameter mappings. More involved behavior, such as coordinating a lightsaber's ignition, movement, and shutdown, lives in a sound controller. Pointer events and rendering stay in the application. That keeps the sound reusable when the same idea moves from a website demo to a game with completely different controls.
A small engine, and sounds you own
Procedural audio already exists, and you can build all of this directly with Web Audio. My focus with AudioBits is making that work easier to start, reuse, and adapt.
The core library is published on npm, has zero runtime dependencies, and works independently of your UI framework:
npm install audiobits
The catalog gives you sounds to start from. Through shadcn's GitHub registry support, you can add an individual item with one command:
npx shadcn@latest add joacod/audiobits/confirmation
That puts editable source in your project. You can change the recipe, keep the parts you like, and connect it to your own interface. Interactive examples also provide reusable sound controllers. The website's visuals stay separate.
I like that boundary. The library handles the audio engine, and the sound design stays yours. You can bring a little confirmation tone into an existing app without adopting the whole showcase around it.
The project is open source under MIT, with the copyable catalog source under the even more permissive 0BSD license.
Ask for a sound and an interaction
AudioBits also has an official Skill and an optional MCP server for coding agents.
The idea is to describe both the sound and what should drive it:
Use AudioBits to make a charging sound that builds while I hold this button, follows the charge level, and releases when I let go.
The Skill guides the agent through creating or adapting a recipe and connecting it to your application. The MCP tools can help it discover catalog items, inspect the installed engine's capabilities, and validate recipe data.
You still need to listen to the result. A valid recipe and a good sound are two different things. But having editable, structured sound definitions gives you and the agent something concrete to refine together.
A sound can describe a space
Echo Probe takes the idea a little further. Your application supplies information about nearby surfaces, including distance, material, intensity, and stereo position. The controller turns that into a pulse followed by a series of audible returns.
Wood gives you a short, dry knock. Metal rings longer. Glass has a brighter, shimmering character. Distance changes when a return arrives, how much energy it keeps, and how its higher frequencies fade. The material keeps its identity while the propagation changes around it.
These are stylized acoustics, but they show the kind of thing I want to explore. A game could feed the controller information from its world. An interactive visualization could make relationships audible. The same sound system can respond to different environments because the application supplies the scene.
That is an exciting direction for me. You can design how a small world sounds when someone interacts with it.
Where I think it fits
Small browser games are an obvious use case: impacts, charging abilities, engines, pickups, and effects that respond to what the player is doing.
There is also room for playful websites, interactive experiments, and tools where sound can give useful feedback. A confirmation tone, a control you can hear changing, or an educational demo that makes a relationship audible. It does not have to be a spaceship to benefit from a little sound, although the spaceship is more fun to demonstrate.
The catalog already includes Energy Charge, Reactive Thruster, and Lightsaber, alongside smaller sound recipes. They are examples you can try and starting points you can take into your own project.
AudioBits is still quite experimental. There are rough edges, and sound quality is something I want to keep improving. I will keep growing the catalog, adding new interactions, and developing better recipes for a wider range of sounds.
That is also what makes me want to keep building it. Every new interaction is a reason to explore what else the browser can sound like.
If you like the idea, a star on GitHub helps other builders find the project.
And if you need a more hands-on explanation, pick up the lightsaber. For research purposes, obviously.
