I built an astronomical instrument in the browser.
It is part of AZIMERIS, an evolving audiovisual artwork in which the website itself is part of the work.
INSTRUMENT 3 uses real ephemeris data for the interstellar object 3I/ATLAS and turns its geometry into a navigable 3D experience.
Rather than presenting the data as a conventional visualization, I wanted to create the sensation of moving through it.
The observer can follow the trajectory, change speed and perspective, move through the planetary system and listen to a sonification derived from motion and geometry.
Three.js became less of a visualization tool here and more like an instrument.
The larger AZIMERIS project also contains audiovisual transmissions and an experimental system called DECIPHER, which can recover information actually embedded in published artifacts.
NO FAKE NOISE.
If something is encoded, it really exists in the artifact.
https://www.azimeris.art
I’d be very interested in what the Three.js community thinks of the instrument — particularly the balance between astronomical information, navigation and experience.
— Uwe Arthur Felchle
Treating the ephemeris data as an instrument rather than a chart is a good framing, and deriving the sound from motion and geometry keeps image and audio honest with each other. One trap from live Web Audio synthesis: after the context suspends to save battery, resume() is async and currentTime stands still, so an envelope scheduled as it wakes can already be expired. In my case only two of six blips played until I added about 80 ms of lookahead, only on wake. A limiter helps too if the user can raise the volume. Are your voices driven directly by trajectory speed, or smoothed first so speed changes don’t click?
Thanks — and yes, that distinction is important to me: it should behave like an instrument, not a chart with sound added on top.The voices are not driven by raw trajectory-speed changes directly. The motion-derived parameters are smoothed before they reach the audio layer, specifically to avoid discontinuities/clicks and to keep the sonic movement perceptually connected to the visual motion. Geometry and relative motion determine the behaviour, but the mapping has its own temporal smoothing.Your wake-up observation is really useful. I hadn’t considered the case where currentTime effectively freezes during suspension and an envelope can already be stale by the time resume() resolves. An ~80 ms wake-only lookahead sounds like a very sensible safeguard. I’m going to test that case explicitly.And yes — limiting at the output stage makes sense, especially once user-controlled gain enters the chain.Thanks for the detailed note. This is exactly the kind of edge case that matters when something stops being a visualization and starts behaving like an instrument.