PCM

This motivation makes sense, but going via wave (and thus WAV) seems unfortunate.

WAV is *almost* but not quite just a wrapper for PCM data, and PCM data really is a pretty fundamental thing that is likely to be just as important and relevant ten years later than the nine-year old first encounters this, but WAV not so much.

I think, from a glance at wave, that it expects you to think about PCM data the way it would have been stored on a CD in the 1990s, specifically as signed 16-bit integers, but that feels very much like something kids shouldn't need to care about at age nine and is less likely to matter in say 2035 than today. Presenting the same capabilities but with normalisation might work, or, if nine year olds are comfortable with decimals, the convention in modern PCM (in software anyway) is the range -1.0 to +1.0 via 0 at 0dB full scale. I don't think there's value in learning that for some crazy reason -32768 through 32767 is the range used by some hardware (signed 16-bit) and there's a _very destructive_ tendency in software that does reflect -32768 to 32767 to not provide saturating arithmetic. In the actual world, with actual sounds, 20000 + 20000 = 40000 and [that being impossible for our 16-bit hardware] so 32767 is the "correct" answer, this correct behaviour for sound is called clipping, but even in Python with 16-bit integers nearby I think you might easily wind up getting -25535 which is horribly wrong (and sounds awful).

Avoiding 16-bit integer arithmetic makes it more likely kids are learning (via cool noises) about how PCM actually works rather than things that didn't work how you'd expect on a 1980s computer.

(if you've ever heard a space rocket take off, you've heard actual clipping - even with sensors designed not to "clip" themselves sound really does saturate like this eventually, but at a loudness which would permanently deafen humans so you can't experience it directly close up)