Frank
Forking someone else’s project to solve one specific problem feels like using a chainsaw to open an envelope. Except sometimes the envelope genuinely requires a chainsaw, and you just have to own that decision.
That’s roughly where I ended up with weft-loom.
The Problem Nobody Talks About With Browser-Based Audio Export
StrudelForge is the live-coding suite built into HookHouse-Pro. Strudel is the engine underneath it, and it’s legitimately impressive, a pattern-based music language that runs entirely in the browser. The idea inside HookHouse was simple: describe a style to the LLM, get valid Strudel code back, play it, export it, upload it to Suno as a seed.
That last step is where everything broke down.
StrudelForge’s built-in recorder does what browser recorders do. It captures live audio through the MediaRecorder API while the track is playing, then hands you a WebM/Opus container. There’s a conversion step that gets you to WAV, but it’s not a clean offline render. It’s essentially a screen recording of your audio. The problems that came with it, playback glitches, export failures, timing artifacts, were real enough that they’re sitting in the repo as filed issues. Not edge cases. Reproducible problems.
The issue I had is specific: the file that goes to Suno as a seed matters. A lot. Suno is working from that audio to build something around it, and if the seed is degraded or glitchy, the output reflects that. I needed a valid 44.1 kHz WAV or a clean MP3. Not “good enough for a browser preview.” Actually clean.
StrudelForge’s recorder couldn’t reliably produce that. It also had no MP3 or FLAC path. So I had two options: fix the recorder inside HookHouse, or find something that already did the export correctly.
Why I Didn’t Just Build It Myself
This is the part I want to be straight about, because I’m not a real programmer. I say that plainly and often. I’ve built real things, HookHouse-Pro, Cookslate, HomeBase, stuff that works and that people actually use, but I’m doing it with AI assistance and a lot of trial and error. I’m not someone who sits down and rewrites an audio engine from scratch.
Rewriting StrudelForge’s recorder to do offline rendering would have meant touching the audio worklet layer, the sound library, the export pipeline, probably the player itself. Those are not small changes. That’s not a weekend feature add. That’s a project inside the project, and there was a real chance I’d break what was already working in the process.
weft-loom already had the offline render. It already had a richer sound catalog than StrudelForge’s base set. It had a validator that actually rejects malformed Strudel code before it tries to play. In a test run it rendered a 2:04 song to a valid WAV without drama. The MP3 I pulled from that came out clean. I uploaded it to Suno. The result was, and I’m quoting my own reaction here, “wicked.”
The LLM panel I bolted onto the fork, the part that actually does the “describe a style, get code back” workflow, is comparatively small. A prompt, a code check, a retry loop. I kept it in separate files specifically so upstream merges from the original project don’t turn into a nightmare.
So yes, I forked an entire project to add a feature that’s maybe 15% of what that project does. The other 85% was the reason I forked it.
What This Actually Costs You
Here’s the honest accounting, because nobody leads with this part.
You now maintain two codebases instead of one. When weft-loom gets upstream updates, I have to pull them in and make sure my LLM panel additions didn’t conflict with anything. That’s not usually hard, but it’s never zero work. It’s a recurring tax.
The sound catalogs between StrudelForge and the weft-loom fork are different. They’re not interchangeable. A Strudel pattern that uses samples from one won’t necessarily play correctly in the other. For now that’s fine, because the fork is a separate tool with a specific job, but it means I can’t just copy patterns between them without checking.
There’s also the simple fact that I am now responsible for something I didn’t write. The core of weft-loom is not my code. I understand enough of it to add to it and to keep the fork maintained, but I’d be lying if I said I had the depth to debug everything inside the audio engine if something goes sideways. I’m betting on the upstream project staying healthy.
And the thing I gave up by not building this inside HookHouse directly is integration. The weft-loom fork is a separate tool. It doesn’t share HookHouse’s session state, its style library, its project management. You’re moving files between them manually. That friction is real.
I made the tradeoff consciously, but I want to be honest that it is a tradeoff. The cleaner audio export was worth it for what I needed, which is better Suno seeds. But clean audio out of the fork doesn’t automatically mean tight integration into the rest of the workflow. That part I still have to solve.
The chainsaw worked. The envelope is open. Now I’ve got a chainsaw to put somewhere.
