stephenhandley
The versioning idea is interesting and something many musicians have to contend with as they work on songs. Personally, I wouldn't want the complexity of take-level versioning, but pinning audio and mix automation to a given mixdown could be useful for tracking the history of a song. It might be more effective to approach this as version tracking / collaboration layer around existing DAW formats rather than a full replacement.
- won't have sufficient positive impact on the bug/feature you are working on
- you don't have time to address at that point in time
- are significant enough to require pay down later
How to address them in terms of tooling and process is a way bigger question
Patrick Soon-Shiong Taking LA Times Public [video]
love the demo https://bungee.parabolaresearch.com/change-audio-speed-pitch
have you thought about wrapping it as an audio unit or vst via juce/clap/iplug so its usable in a daw?
https://juce.com/ https://cleveraudio.org/developers-getting-started/ https://github.com/iPlug2/iPlug2
That said, guessing a bunch of those are meant to be concise examples.
For what its worth my quick take on a lot of the text-based sound coding environments [1] is that they provide a relatively quick way to approach creating audio programmatically differently compared to a more traditional spatial / grid-based daw.
One nice thing about Cracked is that you can treat it as an audio input in Ableton, Logic, etc. and so you could use it to generate a sound to sample / process further in a daw arrangement. I had stumbled across it originally from the author's Wikipedia page which mentions that he uses it to create longer albums / pieces https://en.wikipedia.org/wiki/Bill_Orcutt
Interview with him about it https://www.thewire.co.uk/news/41540/bill-orcutt-releases-op...
[1] https://tidalcycles.org/ https://sonic-pi.net/ https://chuck.stanford.edu/ https://supercollider.github.io/
Desktop wrapper: https://github.com/billorcutt/Cracked
Cat examples: https://idroppedmyphonethescreencracked.tumblr.com/
Cracked - method chaining/CSS-style selector web audio library
Wouldn't the moon would provide better environment for debris shielding and regolith could be used to passively dump heat?
I'm way out of my depth here, so of course I asked ChatGPT 4o to come up with a three paragraph concept sketch for an LLM training facility based at one of the lunar poles:
<gpt>
A lunar pole is an ideal location for large-scale LLM training due to its unique advantages in thermal management and power availability. Near-continuous sunlight at the “peaks of eternal light” allows for stable solar power generation, while nearby permanently shadowed craters provide ultra-cold regions that can act as natural heat sinks — solving one of the biggest challenges of orbital compute: radiative cooling. Compute clusters could be housed in regolith-insulated modules, with heat piped into crater floors or dissipated through passive radiators embedded in the lunar terrain.
The architecture would be modular: prefabricated training units delivered by landers (like Starship) could be arranged into scalable compute farms. Power would be provided by solar arrays on crater rims, with supercapacitors or RTGs as backup. Data transfer wouldn’t require low latency, just high throughput, so high-gain antennas or laser links could periodically sync model weights back to Earth. With no atmosphere, lunar surface conditions are harsh but predictable, and maintenance could be handled robotically.
Compared to the estimated $480 trillion needed for space-based radiators to support orbital training, a lunar facility could achieve similar scale at orders of magnitude lower cost, leveraging the Moon’s surface as both a structural anchor and a thermal reservoir. As launch costs drop and lunar infrastructure matures, this becomes a compelling direction for off-planet AI training.
</gpt>