aneurinandClaude Sonnet 5
1964fda05e
Send our own Cache-Control headers instead of relying entirely on front-proxy configuration, so browsers cache appropriately even when Zampler is reached directly. --static-max-age, --file-max-age, and --api-max-age (all cobra Duration flags, 0 disables caching) cover the three response categories independently; --no-immutable turns off the immutable directive on served files, which is on by default since a file's content never changes for a given ID. The HTML shell always gets no-cache regardless of --static-max-age, since it isn't content-hashed like the rest of the Vite build and must keep revalidating so a new deploy's asset references are picked up. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Zampler
A free, open-source app to help explore your audio sample library.
What does it do?
Zampler scans one or more directories for sample files, calculates their IDs and hashes (checksums), then displays them in an easy-to-use UI, including:
- Embedded audio player with autoplay and loop functions
- Search in file/directory names
- Bookmark and filter your favourite samples for easy access
- Recent playback history so you can go back and find the sample before last that sounded better, actually
Who is this for?
It's mainly just for me. I have a ton of audio samples I hoarded from Computer Music magazine cover CDs over the years, and I never really found a good way to catalogue them for the way I use them in live coding.
Usage
Before you can use Zampler, you need to build it first.
Build the frontend
Zampler serves some static assets for its UI, which need to be built before the backend can be run at all (including for development.) This is simple:
cd frontend
npm i
npm run build
This automatically builds into the (git-ignored) directory internal/server/static which the app will then use.
Build the app
This is also simple:
go get
go build -o zampler
Check out go build documentation if you need more controls.
Run Zampler
Now that you have a zampler binary, you can start it by passing it the path you want to serve files from:
zampler /path/to/audio/files
When Zampler has started, it will tell you what URL to open in your browser to access the UI. This is normally http://localhost:7777 but you can customise this. Run zampler --help for more usage information.
SQLite database
Zampler uses an SQLite database file to keep things organised and searchable. By default this is zampler.sqlite3 in the current directory where you are running Zampler from. You can change this with the --sqlite flag; run zampler --help for more usage information.
Docker
The Dockerfile provides a basic recipe to build a lightweight Docker container that runs Zampler. This is not the recommended approach for most users, but it's available if Docker makes sense for your needs.
By default, the SQLite database is written to /db/zampler.sqlite3 and files are read from /data and both of these directories should be mounted according to your requirements.
Development
Follow the initial build instructions first, because the Go app still needs static assets in order to run.
Developing the Go app is fairly straightforward. Run go run main.go -l trace to test Zampler with enhanced logging.
Frontend development is mostly done standalone using Vite. Copy config.example.json to config.json in the frontend directory to configure the UI for development. Then, run npm run dev to start Vite.
License
MIT. See LICENSE.txt