Should I vibe code
Record and arrange a simple multitrack song in a browser and export stems
The sequencer is an afternoon. Latency compensation is a fortnight. The sample library is a legal department.
?
Their verdict, the Music Makers Premium price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Nothing here can hurt anyone, which makes this the rare entry where the whole argument is craft. A loop sequencer in the browser is a genuinely delightful afternoon: schedule buffers on the AudioContext clock, draw some rectangles, and by dinner you have something that grooves. Then you plug in a microphone and the project changes species. Recording means round-trip latency you must measure and compensate, monitoring without feedback, and an arrangement where the take you just played lands forty milliseconds behind the take you played it against — audible, unfixable by ear, and invisible in the code. Then you press export and discover that the offline render does not sound like what you heard. And underneath all of it sits the thing that is not code at all: Soundtrap's loops, instruments and effects are a cleared, licensed sample library, and no amount of agent time produces one of those. Build the sequencer. Do not expect a DAW.
What actually breaks
not "if". the specific failures.
- The clock. setTimeout and requestAnimationFrame drift, so anything not scheduled ahead against AudioContext.currentTime will wander, and the tell is a tempo that feels fine for eight bars and wrong by thirty-two
- Recording latency. The gap between what you hear and what lands on the timeline is real hardware round-trip, it differs per device, and unless you measure and compensate it every overdub is late in a way nobody can play around
- Autosave, which saves the arrangement and not the audio. The project file survives the crash and the take you just nailed does not, because it was still in memory
- The export, when OfflineAudioContext renders a mix that differs from playback — usually a plugin or worklet that behaved differently at a non-realtime rate, or a tail that got cut
- Monitoring, where the moment you route input to output without care you have built a feedback loop and everyone in the room finds out at once
- Safari and iOS: audio that will not start without a user gesture, worklets with different buffer behaviour, and a tab that gets suspended mid-take
- The library, which is not a bug but a wall. Loops, instruments and effects that are cleared for release are the product; anything you scrape is a copyright problem waiting for the track to do well
- Collaboration, if you add it, which is operational transforms on a timeline plus audio upload and is a different project entirely
Is that you?
the verdict is a default, not a law
- It is loops and MIDI only — no microphone, no latency compensation, no problem
- You are building an instrument or a toy rather than a place to keep work you care about
- Every recorded buffer is written to disk the instant recording stops, before anything else happens
- The samples are yours, or genuinely public domain, and you can point at where they came from
- Real takes you cannot re-perform will live in it, and you have not tested pulling the power out mid-session
- Other people will record into it, because now you are the reason someone lost a vocal
- You are shipping a sample pack you did not clear
- You need the export to be the deliverable and have not verified that the rendered file matches playback, sample for sample
If you build it anyway
the checklist, then the prompt that enforces it
- Schedule everything against AudioContext.currentTime with a lookahead scheduler. Never drive audio timing from setTimeout, setInterval or animation frames — use those to decide what to schedule, not when it plays.
- Write recorded audio to disk continuously, not at stop. A crash should cost you seconds of performance, never a take.
- Measure round-trip latency with a loopback calibration step and store the offset per device. Then show it in the UI, because a wrong number is worse than no compensation.
- Keep audio files immutable and content-addressed on disk, with the project file as a pointer list. Then a corrupt project is recoverable and a destructive edit never touches the source.
- Make every edit non-destructive: trims, fades and gain are metadata over the original buffer. Undo that mutates audio is how a project becomes unrecoverable.
- Verify the export against playback with an automated null test on a reference project. A mixdown that quietly differs is the bug you find after you have sent the file.
- Keep provenance on every sample — source and licence, stored with the file. The day a track does well is a bad day to start looking for it.
I am building a small browser DAW: multitrack timeline, loops, microphone
recording, mixing and export. It is for my own music, so the thing I cannot
afford to lose is a performance. Work in this order.
1. Build the storage model before any audio. Recorded audio is immutable,
content-addressed files on disk; the project is a JSON pointer list of clips,
offsets and gains. Never rewrite a source file.
2. Persist recorded audio continuously while recording, not on stop. Write a
test that kills the process mid-take and asserts the partial take is
recoverable and correctly placed on the timeline.
3. Use a lookahead scheduler driven by AudioContext.currentTime, scheduling at
least 100ms ahead. A timer decides what to enqueue, never when it plays.
4. Add latency calibration before recording exists: play a click, record it
through loopback, measure the round trip, store the offset per input device,
show it in the UI, and apply it when placing recorded clips.
5. Implement monitoring carefully, default it off, and explain the feedback path
in a comment.
6. All editing is non-destructive metadata: trim, fade, gain, mute. Undo is a
command stack over that metadata and never mutates audio data.
7. Export via OfflineAudioContext, then verify it: render a reference project,
compare against a captured realtime pass, and fail if they diverge beyond a
tolerance. Include reverb tails.
8. Store a licence and source field with every sample and refuse to import
anything without one. Do not bundle a sample pack you cannot show me a
licence for.
9. Handle Safari and iOS explicitly: resume the AudioContext on a user gesture,
survive tab suspension, do not assume worklet buffer sizes.
10. Export stems and a project bundle as ordinary files in a documented folder
layout, so my work is not trapped in your schema. Out of scope: real-time
collaboration, plugin hosting, notation and mastering.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
As soon as recording real performances is the point. Twelve dollars a month buys the two things a weekend cannot produce: a cleared library of loops and instruments you are allowed to release music with, and an audio engine whose latency compensation and mixdown have been debugged against thousands of soundcards. Also worth saying plainly — if you want a free desktop DAW rather than a subscription, several excellent ones already exist and none of them require you to write a scheduler.
$11.99/mo is cheaper than your weekend.
Keep the project as a directory rather than a database and there is no exit problem at all: WAV files at full resolution, a JSON manifest describing clips and levels, one folder per song. Any DAW will import the stems, which is the part that actually matters, and the arrangement is a text file you can read in ten years. What will not survive is the mix — automation curves, effect settings, anything you invented — so bounce a reference mixdown alongside the stems every time you finish a session. That single WAV is the version of the song that outlives every tool you will ever use.
Actively maintained Web Audio framework with a transport and lookahead scheduler, which is the hard timing problem already solved.
Full open-source DAW under continuous development, and a working answer to every latency and recording question you are about to hit.
Questions
Their estimate says one sitting. Is that wrong?
No, and it is careful about it — they call it a consolation build. A loop sequencer with a step grid and a play button really is a sitting, and it is a great sitting. Everything that makes it a recording studio rather than a toy is elsewhere: latency, persistence, mixdown fidelity and a library you are allowed to use.
Why is losing a take treated as a serious failure when nothing here is dangerous?
Because it is the only genuinely irreversible thing in the project. A wrong pixel is a bug, a crash is an afternoon, but a performance happened once and the version you played at midnight is not the version you will play tomorrow. That is the whole reason the storage model comes before the UI.
Can I just use free loops I found online?
Only if you can say where they came from and under what licence. "Royalty-free" on a download page means nothing on its own, and the risk is asymmetric: it costs nothing while nobody hears the track and becomes a real problem exactly when something works. Store the source and licence with every sample from the first import and the question never comes up again.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice