cochlear
Joined 1 year ago
Joined 1 year ago
I've made a couple things along these lines over the past year. One is a fun, Halloween-themed toy:
https://blog.cochlea.xyz/theremin.html
The other is a (slightly) more serious exploration of multivariate time signals as a control signal for an instrument. In the latter case, the instrument is learned/inferred from a segment of input audio:
https://blog.cochlea.xyz/resonancemodel.html
This is a really neat idea! Like others here, I'm not a huge fan of the hyper-dense and dripping-with-ai UI, though.
I've written one other AudioWorklet at this point, which just runs "inference" on a single-layer RNN given a pre-trained set of weights: https://blog.cochlea.xyz/rnn.html. It has similarly mediocre performance.
Thanks for all the great tips, and for your work on Glicol!
Now that I understand the basics of how this works, I'd like to use a (much) more efficient version of the simulation as an infinite-dataset generator and try to learn a neural operator, or NERF like model that, given a spring mesh configuration, a sparse control signal, and a time, can produce an approximation of the simulation in a parallel and sample-rate-independent manner. This also (maybe) opens the door to spatial audio, such that you could approximate sound-pressure levels at a particular point in time _and_ space. At this point, I'm just dreaming out-loud a bit.
Working with AudioWorklets (https://developer.mozilla.org/en-US/docs/Web/API/AudioWorkle...) has been really cool, and I've been surprised at what's possible, but I _haven't_ yet figured out how to get good feedback about when the custom processor node is "falling behind" in terms of not delivering the next buffer quickly enough.
My assumption has been that any physics engine that does soft-body physics would work in this regard, just at a much higher sampling rate than one would normally use in a gaming scenario. This simulation is actually only running at 22050hz, rather than today's standard 44100hz sampling rate.
Apologies if it isn't clear, but the animated gifs are meant as an illustration of the iterative encoding process, where the encoder decomposes the signal step-by-step, as in matching pursuit. I'll be sure to clarify that point.
I'll add a paragraph on compression rates/ratios, although that isn't necessarily the main focus here; codecs may compress a signal, but they might also transform it into a more useful, easy-to-understand and easy-to-manipulate representation.
https://blog.cochlea.xyz/sparse-interpretable-audio-codec-paper.html