REVE Model 1

The Opportunity

I hold a Master's degree in Music Technology from NYU, and digital signal processing has always been the intersection where my technical and creative interests meet. I had already built FripperTripper, a browser-based synth using the Web Audio API. REVE Model 1 started as a question: could one person, using AI coding agents, port that synth into a real, hand-rolled native iOS audio engine (not a thin wrapper around someone else's DSP library) and ship it to the App Store solo?

That meant writing the entire signal chain (oscillators, filter, envelopes, delay, limiter) from scratch in pure Swift, with only a thin layer of AVFoundation at the very edge to get audio in and out of the device. No AudioKit, no third-party DSP library, no dependencies at all.

Product Process

1. 01

   Concept & Reference

   Used an existing web synth I'd already built as the reference implementation, and scoped what a "real" native port meant: a fully hand-rolled DSP engine, not a thin AVAudioEngine skin over someone else's library.

2. 02

   Design

   Designed a paged front-panel layout with a visible page selector (not swipe-only), a non-modal keyboard drawer so both hands can stay on the controls while a note rings out, and a glissando keyboard gesture built for live playing.

3. 03

   Build

   Wrote the full signal chain (VCO, ladder filter, envelope, LFO, arpeggiator, echo, limiter) as a pure-Swift, Foundation-only DSP core in Swift 6, wrapped in a single thin AVAudioSourceNode, with zero third-party dependencies.

4. 04

   Launch & Iterate

   Shipped the first release, renamed the app to REVE Model 1 shortly after, then iterated post-launch: a 100-patch factory preset bank, iPad layout support, and an AUv3 plugin extension so the same engine runs inside AUM, Logic Pro for iPad, Cubasis, and GarageBand.

AI-Native Product Development

REVE Model 1 was a deliberate stress test of AI-agent-assisted product development, not "using AI" as a talking point, but actually wiring agents into the work across engineering, design, QA, and launch, and owning the judgment calls that go with it. The evidence is in the repo itself, not just the pitch:

• Velocity as a signal. Git history shows the entire native engine, including the VCO, filter, envelope, LFO, arpeggiator, delay, limiter, a full SwiftUI control surface, and a working preset system, went from initial commit to a shippable, TestFlight-ready build in about 27.5 hours.
• Agents plan, not just generate. Before the AUv3 plugin extension was built, the repo already contains a written implementation plan that cites specific file and line numbers as verified grounding facts, flags dead code found by direct inspection, and lays out numbered stages with a verification step at each one. The shipped extension matches that plan closely, down to the manufacturer and subtype codes it proposed.
• Troubleshooting, not just code review. Two real production issues, a silent audio-quality regression from the OS not consistently re-granting the requested sample rate on session reactivation, and a crash traced to a scene-phase transition tearing down the delay buffer mid-render, were root-caused and fixed, not just patched over.

Working with non-determinism: the harder product skill wasn't prompting. It was deciding when to trust agent output outright, when to verify it, and when to override it. That evaluation loop, run consistently across engineering, design, and troubleshooting decisions, is the actual muscle behind "AI fluency": operating at the level of prompting, evals, and agents, not just talking about AI as a topic.

Key Features

Analog-Style Voice Architecture

A monophonic, last-note-priority voice (SH-101-style) with a VCO (saw, pulse, sub, noise), a 4-pole ladder filter, one ADSR driving filter/PWM/VCA, and an LFO with pitch-mod routing.

Echo & Limiter FX Rack

A hand-rolled circular-buffer delay with adjustable repeats and time, plus a feed-forward peak-limiter with a live gain-reduction meter to keep the echo from blowing out.

Live-Performance Keyboard

A single continuous drag gesture spans the on-screen keys for real glissando, with a Hold/latch mode so both hands stay free for the front-panel knobs.

AUv3 Plugin

The same engine runs as an Audio Unit instrument inside AUM, Logic Pro for iPad, Cubasis, and GarageBand, with MIDI input and full session save/restore.

Fully On-Device

No network calls, no third-party SDKs, no tracking. The privacy manifest declares zero data collection, and everything runs locally on the device.

Design & UX Decisions

Every interface decision was weighed against a single question: does this help someone play, or does it get in the way? That bias shaped several specific choices.

• No onboarding, no about screen. An about screen was built, then removed, so the app launches straight into the playable front panel instead.
• Paged, not scrolled. The full control set doesn't fit one phone screen at a usable size, so it's split into three tappable pages with a visible selector, rather than a deep scroll or swipe-only paging that's harder to discover.
• A non-modal keyboard. The on-screen keyboard lives in a slide-up drawer instead of a sheet, so a held note and a knob sweep can happen at the same time, which is core to how the instrument is actually played.
• Brand color sampled from the icon. The UI accent color was pulled directly from the app icon artwork rather than a stock system color, and the whole app is forced into dark mode.
• Bugs fixed at the root, not the symptom. A sample-rate renegotiation issue was silently making the audio duller on session reactivation with no error thrown, and a scene-phase race was tearing down the delay buffer mid-render during a reported crash. Both were traced to their actual cause and fixed.

Video Gallery

Tech Stack

Reflections & What's Next

Shipping solo, with AI agents doing real engineering work (not just scaffolding), proved the model holds up on a real, App-Store-approved product, and the post-launch iterations (a 100-preset factory bank, iPad support, and the AUv3 plugin) show it holds up for ongoing product work too, not just a single sprint. Next up: [preset sharing/import], [standalone MIDI support], and [Android exploration], prioritized against real user feedback once usage data is in.