BassoonTracker: an Amiga tracker that runs in a browser tab with no build step

A tracker, in a browser, with no dependencies

BassoonTracker is a browser-based old-school Amiga music tracker in plain old JavaScript, and the homepage has a live version at stef.be/bassoontracker.

The description of what it does is short and specific. It plays and edits Amiga Module files and FastTracker 2 XM files. If you have ever heard of Protracker or Fasttracker, then you know the drill, and if not, then you are probably too young.

The requirements are what a modern browser gives you. It requires a modern browser that supports WebAudio, and it is tested to work on all major browsers, desktop and mobile. The mobile floor is iOS 9 or Android 6. And there is a specific limitation stated up front: Midi support is not available in Firefox or Safari.

The file structure is worth reading because it explains the design. The top level has dev.html and index.html, a script/ directory holding the plain scripts, a skin/ directory with the spritesheet and its source, an api/ directory for the modarchive and modules.pl integrations, an auth/ directory, a data/ directory, a player/ directory for the standalone player examples, a playlists/ directory, a versions/ directory, a tools/ directory, and both a sw.js service worker and a manifest.json, which means the tracker is installable as a progressive web app.

There is no build system in the runtime sense. The package.json is four scripts and one optional dependency, and the optional dependency is vite at 6.3.6, which is the key detail. Vite is a build tool, so it is listed as optional because you do not need it to run the tracker.

The primary language is JavaScript, the licence is MIT, and the project is hosted at www.stef.be/bassoontracker. The single release is v0.5.0 from 2024-09-06, and the package version is 0.5.0.7, so the published version has moved past the tagged release. The repository is not archived, with the last push on 2026-09-11.

Running it: serve the folder, or open dev.html

The How to Run section is the shortest installation guide you will find on a project like this, and it is worth reading because the zero-build claim is real rather than aspirational.

BassoonTracker is a web application that runs in your browser. Just serve index.html from a webserver and you're good to go. That is the whole instruction for the production build, and the reason is that the built artefact is static files.

For local development the documentation suggests Spark if you would rather not fiddle with node and npm. Download the binary for your platform, drop the Spark executable in the folder where you downloaded the BassoonTracker source files and run it. If you then point your browser to http://localhost:8080/dev.html it should work.

And the How to Build section makes the optional nature of the build explicit. BassoonTracker doesn't need building, the build step is optional, there are no runtime dependencies. Just open dev.html in a browser to load the plain uncompressed scripts, which you can also do by running vite or npm start on the command line.

That is the whole architecture in one sentence. The tracker is a set of plain scripts that the browser loads directly, and the optional build exists only to produce a compressed version for people who want one.

The build itself is Vite. If you like you can build a packaged version, and if you do not have vite installed globally you install it with npm i. Use vite build, or npm run build, to build the compressed files, and index.html will be created. The package.json confirms this mapping, with build mapped to vite build, start to vite, and a third script for the skin.

That third script is the graphics pipeline. If you make changes to the graphics, use npm run skin to build the spritesheet. It compacts all files in skin/src to a single .png file and creates a spritemap. The skin directory in the repository listing holds both the source assets and the generated output, and the same script is in package.json as skin mapped to node skin/generate.js.

There is a fourth script, deploy, which runs VITE_OUTDIR=live vite build, so the deployment build writes into a live directory rather than the default output. That is a small detail that tells you the project is deployed as static files to a directory that the web server points at, which is consistent with the serve index.html instruction.

So the deployment story is: static files, a directory, and a web server. There is no backend, no build pipeline to run in CI, and no state to manage. For a tool like this that is the correct trade.

What the tracker actually implements, effect by effect

The feature list is unusually complete about the effects, and the two accuracy figures are the most honest numbers in the document.

All Protracker audio effects are supported, described as 99 percent accurate, with the caveat that in case of historical differences in playback engines the author tends to follow the Protracker 2.X one. The list covers portamento and frequency slides, effects 1, 2, 3, 5, E1 and E2. Vibrato, effects 4, 6 and E4. Tremolo, 7 and E7. Arpeggio, 0. Glissando, E3. Sample offsets, 9. Volume slides and settings, A, C, E10 and E11. Position jumps, B. Pattern breaks, loops and delays, D, E6 and E14. Speed settings, F. Sample delay, cut, retrigger and finetune, E13, E12, E9 and E5. And the lowpass LED filter, E0.

Almost all FastTracker audio effects are supported, at 97 percent accurate, adding volume and panning envelopes, auto vibrato, multiple samples per instrument and extended volume commands.

That mapping is genuinely useful, because the effect letter is how the format itself is specified, and a list that says which effect codes are supported and which are not tells you whether a module will play correctly.

On top of the tracker effects there are per-channel effects for low, mid and high frequency, panning and reverb control, plus mute and solo tracks.

The editing side has pattern data and sample property editing, ranges and cut, copy and paste for quick editing, and full undo and redo in both the pattern editor and the sample editor. There is an integrated sample editor where you edit and slice your samples right inside the tracker. Up to 32 channels are supported. The undo and redo entry is marked as done in the future plans, with the strikethrough still visible.

Sample import covers 8bit WAV, 8SVX and RAW samples, and also any other format AudioContext can read, like .mp3 and .ogg. Export goes to .mod, .xm, .wav and .mp3.

And there is a piece of history worth noting. It includes the historic ST-01 and ST-02 sample disks, released in 1987, as well as a bunch of others. Those are the Amiga sample sets that tracker music is built on, and shipping them is the difference between a tracker that makes sounds and one that makes music.

The library side has an integrated sample editor, playlists and favourites, and integration with the modarchive API for several thousands of music files and the modules.pl API for even more. Your Dropbox account can be connected to directly read and write your own files.

The player, the plugin plan, and what the standalone API offers

The last part of the documentation covers two things that change what the project can be used for: embedding the playback engine in your own site, and the plugin system that is planned but not built.

The Player section says that if you want to integrate the BassoonTracker playback routines in your own website, you should check out the Standalone Player examples in the player/ directory. That directory is in the repository listing, so the playback engine is not locked inside the tracker interface. The same is true of the api/ directory, which holds the integrations with the modarchive and modules.pl services, and the auth/ directory, which is presumably where the credentials for those services and for Dropbox live.

That distinction between the tracker application and the playback routines is the same one that makes the project a library as well as an application. A tracker is a fairly specialised piece of software, and the people who want it are often building something else that needs to play a module, such as a demoscene production, a game, or a site with a retro theme. The player examples are the entry point for that.

The plugin plan in the future list is the more speculative half, and the entries are specific enough to be interesting. Jukebox plugins with filtering on genre or rating, so you hit play and let it perform. A more expanded sample editor with audio processing features, probably as an external plugin. And an entry for integrating the DAW project, which is the Bitwig DAWProject format for sharing musical structure between a DAW and a live performance tool, which is the natural bridge for a tracker used in a live setting.

There is also a set of instrumentation-related plugins in the list. The File System Access API entry is the one that matters most for day to day use, because it would mean the tracker can read and write files directly from the browser's own file picker instead of going through a download and an upload, which today is the most tedious part of working on a module in a browser. The docs/ directory is where the fuller documentation lives, and the site is stef.be/bassoontracker/docs.

So the project is three things at once, and the repository layout reflects that: an application you can run from a static folder, a set of playback routines other people can embed, and a plan for a plugin ecosystem. The plugin part is the least built of the three, and the future list is candid about that, with a struck-through entry for the simpler HTML/CSS layout marked done but not maintained, which tells you that even the completed items in that list do not get attention.

The gaps, stated plainly, and the browser constraints

The Missing features and bugs section is unusually explicit, and it is the section that should decide whether the tool is right for you.

Several FastTracker features are not fully supported yet. Tremor. The set envelope position command. Panning slides. And two with consequences beyond playback. PingPong loops are unrolled to normal loops, and while there is no difference in sound, if you save your XM file your samples will have changed. And when writing XM files, patterns are not packed, so the resulting files will probably be a little bigger than when saved with the real FastTracker 2.

Both of those are file format fidelity issues, not playback issues, and they matter for exactly the use case that would worry you: a module you are going to hand to someone who will open it in the real FastTracker 2. The sound is the same, but the file is not what they expect, and the author says so rather than glossing it.

The browser constraints are the other half. Safari doesn't support WebAudio StereoPanners, so songs will be played in mono on Safari. And Safari and Firefox don't support the Web Midi API, so no midi on those browsers. The requirements section says the same thing more briefly, that Midi support is not available in Firefox or Safari.

The playback accuracy question has its own separate answer. The playback engine has gone through extensive compatibility testing, but as the Protracker code itself is somewhat messy and muddy throughout different versions, there's always room for improvement. And there are still some very specific Protracker 1 and 2 playback quirks that are not implemented, and probably never will be as they are too bat-shit-crazy, with a link to a quirks document.

The instruction that follows is the right way to use that. If you find a module that doesn't sound the way it should, let me know.

The future plans list is a good indicator of the project's direction and it is honest about its own compromises. There is a struck-through entry for a simpler HTML/CSS-based layout, with the note that it is done but not maintained, and the question of whether the canvas approach is too heavy for really large screens. There is a struck-through entry for Nibbles, the Breakout clone, with the note that we do have it. Local file system access through the File System Access API is on the list. Export and import of .xi instruments. 3SM and Screamtracker file support, maybe OctaMED too. Synth or FM instruments alongside sample instruments. Multiple notes per track. A horizontal block compose interface for reusing and combining tracks instead of copying them endlessly. And more effects such as echo, reverb and flange, implemented with graphical track envelopes, which the author notes would require yet another new file format, and that this seems inevitable.

Editorial conclusion

BassoonTracker fits a musician or developer who wants to write tracker music in a browser tab without installing a native tracker, who needs to open and export Protracker modules rather than produce a finished song, and who is willing to work around a few unimplemented FastTracker commands. It is the wrong tool if you need a modern tracker with virtual instruments and unlimited effects, and the wrong choice if you need a saved XM file to be byte-compatible with FastTracker 2, since patterns are not packed and the samples change when ping-pong loops are unrolled. Before adopting, read the quirks document, check whether your browser supports the Web Midi API, and test your target module's specific effects against the accuracy percentages stated in the documentation.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. steffest/BassoonTracker on GitHub