Inspiration
What it does
How we built it
Challenges we ran into
Accomplishments that we're proud of
What we learned
Inspiration
Winamp was the first piece of software that made my music library feel like my library — the skin, the spectrum analyzer, the playlist that never quite worked. I wanted to find out whether a 1999 interface could be reanimated by 2026 tooling without turning into a nostalgia skin. Kiroween's Frankenstein category was the excuse: take a dead desktop player and stitch it to a modern LLM agent that can actually make decisions about your music.
What it does
FrankenAmp plays your local library through a resurrected Winamp-style interface, but the playlist is not static. An agent reads the current track, its audio features, and a one-line prompt ("something for a rainy walk"), then queues the next tracks and drives the visualizer in real time. Skip a track and the agent adapts instead of restarting. Every action is visible in a log panel, so you can see why a song was chosen.
How I built it
- Player and UI — TypeScript with the Web Audio API. The classic skin is rebuilt in CSS with the real bitmap proportions, so it scales without blur.
- Analysis — a small Rust module compiled to WebAssembly computes FFT and tempo estimates on the audio thread, then hands the buffer to the renderer.
- Agent layer — an LLM agent receives the track metadata and analysis summary, and returns a ranked queue plus visualizer parameters as structured JSON. It runs through a Kiro agent hook so the same logic works from the IDE and from the browser build.
- Kiro — I wrote the data contracts as Kiro specs first, used steering files to keep the agent's output schema stable across iterations, and used hooks to run the WASM build and the type check on every agent edit.
Challenges
The hardest part was latency: an LLM call cannot sit between "track ends" and "next track starts." I solved it by having the agent prefetch a queue of six tracks ahead of playback and only re-plan when the user intervenes. The second problem was keeping the agent's JSON reliable — early versions returned prose. Pinning the schema in a Kiro spec and validating every response before it touched the queue fixed that.
What I learned
Specs are worth writing before the agent writes code. Every time I skipped one, I spent longer repairing the generated output than I would have spent writing the spec. I also learned that a "seamless" agent experience is mostly engineering around the model's latency, not prompting.
What's next
Spotify and local-file parity, a visualizer preset editor, and letting the agent explain a queue in natural language when you ask it why.
Log in or sign up for Devpost to join the conversation.