External
Presets sound different, and it's unclear where to start adjusting amp, cabinet, EQ, drive, or modulation order.
Case Study · TonePilot
Describe the tone you want —
AI builds the starting multi-effects setup.
An AI tone-setup assistant for players who find multi-effects units overwhelming. It builds a starting point for your gear and taste, and explains every adjustment.
후크 (예술이야 반복)1:40 → 1:57
짧고 강렬한 후크 파트, 하이게인 유지하며 딜레이/리버브 강조.
AMP · Gain7/10하이게인 유지
DLY · Dual DelayTime 450ms리듬 악센트 강조
REV · SwellDecay 40%악센트마다 스웰감
👉 P04 프리셋 호출, 픽업 1번 포지션 유지.
Status
Prototype
Role
Planning · AI workflow design · UX
Users
Guitarists who want better tone but find multi-effects units hard
Updated
2026-07
Shared Context
The player's situation
You bought a good guitar and a multi-effects unit, but the chains, amps, cabinets, and endless numbers make the path to your sound feel impossible. Downloaded presets sound different on your gear.
| Layer | What TonePilot users want |
|---|---|
| Surface need | Quickly build a tone close to the song, genre, or feel I want — on my own guitar and unit. |
| Inner need | Focus on playing, without feeling defeated by menus and jargon. |
| Latent need | Not just copy someone's preset — understand why it sounds this way, and own my tone. |
Problem
The villain and three dimensions of the problem
The villain
The multi-effects unit's complex signal chain, and parameters that shift with every gear and environment combination
Internal
Even with good gear, the sound isn't right — and it feels like your own skill is the problem.
Philosophical
Nobody should have to become an audio engineer just to enjoy the guitar.
Options & Objections
Alternatives compared
| Alternative | Strengths | Limits | Judgment |
|---|---|---|---|
| Factory presets | Instantly usable | May not match your guitar, pickups, output gear, or environment | Quick baseline |
| YouTube / community patches | Many references with explanations | Don't reproduce on different devices, firmware, or gear | Reference material |
| Manual learning / expert setup | Deep understanding, high quality | Big time and knowledge barrier | Long-term path |
| AI setup + explanation | A starting point matched to your gear and sound, with iterative feedback | Gear data, taste interpretation, volume differences, no single answer | TonePilot's chosen direction |
| Fully automatic, fixed | Minimal setup burden | The player loses taste and control | Rejected |
Plan
The player's plan: a six-step flow
Pick your gear
Enter your multi-effects model, guitar, pickups, and output (amp/PA/headphones).
Describe the tone
Choose the song, genre, part, desired feel, or a reference track.
AI setup
Within blocks your device supports, it proposes a starting chain and key parameters.
See the reasons
Each block's role, "why this value," and anything incompatible is explained.
Play and give feedback
Too bright, muffled, noisy, not enough gain — in your own words.
Adjust and save
AI proposes revisions; you compare, confirm, save, and export.
Solution · Information Architecture
Key screens and information architecture
| Screen | Content | Design principle it proves |
|---|---|---|
| Setup profile | Guitar, pickups, multi-effects, output, firmware | Real gear context comes first |
| Tone brief | Genre, song, part, feel, reference tone, environment | The user's language, not jargon |
| Patch proposal | Signal chain, blocks, parameters, expected character | A concrete, usable starting point |
| Why this tone | Reasons per choice, high-impact values, gear constraints | Explainability and learning |
| Feedback loop | Simple feedback: bright/dark, gain, noise, space | Preferences tuned through conversation |
| Patch library | Versions, per-gear variants, memos, comparison, export | User ownership and reuse |
AI vs User Control
What AI does, what the player decides
AI assists
- Generating gear-compatible blocks and chain candidates
- Parameter starting points with expected-sound explanations
- Revision proposals and comparison points from feedback
- Flagging gear constraints and uncertainty
The player decides
- Desired feel, playing part, priorities
- Judging good and bad after actually playing
- Choosing revisions, fine-tuning, final save
- Whether to share, delete, or export presets
Technical Questions
Questions the technical design addresses
Good questions, published honestly — rather than inflated answers.
What common schema can express each device's blocks, parameters, ranges, and ordering constraints?
How do user words like "warm, chewy, crisp, muffled" map to acoustic characteristics and setting changes?
How do we explain the gap between a reference track and the user's gear — without promising exact replication?
How much recommendation reasoning and uncertainty can a beginner absorb without being overwhelmed?
Sound evaluation depends on recording, playing, and volume — how should tests be designed?
Safety & Compatibility
Safety, compatibility, and trust principles
Explicit compatibility
Supported devices and firmware are stated; blocks or ranges that don't exist are never invented.
Output safety
Warn about output levels and sudden volume changes; use safe defaults.
Reference, not replication
Artist and song references describe tone characteristics — they never promise exact copies.
Undo anytime
Recommendations are starting points; compare before/after and roll back to any previous version.
Evidence & Success Metrics
Evidence and success criteria
| Evidence asset | Success criteria to measure |
|---|---|
| Per-device parameter schema | Accuracy of supported devices/blocks; rate of incompatible suggestions |
| User input → patch examples | Whether the first proposal loads on the real device |
| Before/after feedback patches | Revisions and time needed to reach a usable tone |
| Explanation screens | Whether beginners understand the reasons behind settings |
| A/B playing tests | Satisfaction, preference match, confidence change |
| Limitation & error log | Failure types per gear/environment and improvement plans |
Status
Labeled "Prototype" because the per-section patch guide screens work. It will move to In development/MVP once real-device testing and repeated use are confirmed.
Next Step & Research
Next steps and research questions
Next
Device schema and first patch prototype
Define the block/parameter schema for one representative multi-effects unit, and validate the tone brief → patch proposal → device load flow.
Research
Explainable recommendation and creative agency
How do reasons and adjustment rights affect a beginner's trust and learning? — continued on the Research page.