How this was made

A learning project and musical scaffold

Co-written, GW and Claude Code

This site is a learning project. It is a first scaffold for hearing environmental data, not a finished instrument, a validated method or expert composition. I made it working with Claude Code, which did most of the coding and development, and assistance in strategy for selecting, transforming and sonifying spatiotemporal data.

What I brought

The question and the curiosity. Could a year of a river, or seventy years of an ocean, be heard, and would hearing it teach something a chart doesn’t?
Domain knowledge. Years of practice in watershed planning, flood mitigation work and local government in Alberta and BC. I choose the records I’m interested in exploring out of curiousity and my interest in exploratory data analysis.
The literature. I am building a working library of academic papers on music theory, sonification, auditory display and data analysis, and use coding agents to analyze and synthesize ideas from this literature for my review and integration into music.
A commitment to reproducible, reviewable research. I’m trying to develop in open, reviewable ways by tracking source data, licencing, transformations and simulations so that the audio renders are repeatable from the code. This is not perfect: I usually record the intent and initial judgement enough to be trackable, and some pieces incorporate listener choices as they listen, which makes them less deterministic.
The environment the work happened in. I maintain a personal research and development environment I call the ‘habitat’ (notes, a literature library, open source software tooling, datastore, decision logs and review workflows) that the agent works inside. The skills and workflows help maintain the decision records, provenance tags and pre-publication reviews underlying this site.

What Claude Code led

I have almost no training in music theory and am a beginner in Python. So I requested Claude’s assistance in developing the following, with the intent that my skill and judgement in these topics grow as I work on more pieces:

The music theory: the mode ladder, chord loops, voice leading, rhythms and orchestration.
Much of the data-to-sound mapping: which variable drives which instrument, the thresholds, smoothing and hysteresis, and the balance of the mix.
All of the code: the data fetching, the sampling and synthesis engine, the scores, the listening companion and this website.
The analysis and checks: derived variables, the quality-check plots, and the reproducibility tests.
Much of the writing on this site (though that is changing).

I also use multiple sub-agents to review code before release, including Google Gemini models, because I am not a software engineer.

Why not just ask a chatbot?

I’ve tried asking AI assistants to make a sonification, but I was unsatisfied - not with the sound, but with the experience. There was no friction or learning for me, and I couldn’t review the mechanics behind the music to deeply understand the planning, decisions, and options used. It was a black box. In this project I hope to practice the opposite so that every step can be reviewed:

Every data source is named and fetched by a script, so you can check the records against their providers.
Every mapping from data to sound is written down, in the code and on the pages, with its provenance tag.
Every render can be rerun exactly. The same code and data produce the same audio, byte for byte, and quality-check plots show whether each layer speaks when its data says it should.
Every decision has a record. What was tried, what changed and why were logged as the work went, and the code was independently reviewed before publication.

What that means for the listener

The data are real and sourced. Every record is credited on the Methods pages, and the scripts available in the GitHub repository fetch it from the provider.
The musical and code choices are one reasonable first attempt, made by an AI system under a practitioner’s direction. They are interpretive, not authoritative, and a composer or a software engineer would make many of them differently.
It is a scaffold to grow from. The code is open (Mozilla Public License 2.0) and meant to be read, questioned and changed. Suggestions and corrections are welcome as issues on GitHub.