If you ask for a mix revision by saying only “make it more powerful” or “make it feel brighter,” the client and the engineer may imagine different results. Using more technical terms is less important than clearly stating which version you reviewed, where the issue occurs, what you hear, and how you want it to change.
A revision list is not a document that dismisses subjective impressions. It is a memo that translates those impressions into tasks another person can reproduce.
Choose one version as the review reference
Add a version number and date, such as “mix_v03_20260717,” and make sure everyone listens to the same file. If different versions remain in chat, email, and cloud storage, state which one is currently under review.
Turn off loudness normalization and EQ in the playback app, and share the same file format whenever possible.
Write the timecode and the sound you mean
Include the time, section, and target, such as “1:24, second chorus, end of the lead vocal phrase.” “Fix the chorus” covers too much and can lead to changes in the wrong element.
If playback offsets make timecodes unreliable, add the bar number or a lyric cue. For a problem that lasts several seconds, write both the start and end times.
Separate what you hear from what you want
“The snare sounds in front of the vocal” describes the current state. “I want it slightly farther back” describes the goal. Rather than prescribing “cut 5 kHz by 3 dB,” explain the audible problem and purpose first so the engineer can choose the right combination of level, EQ, reverb, or another process.
If you do want to request a specific process, include the reason, such as “the consonants feel sharp, so I would like stronger de-essing.”
Divide priorities into required, preferred, and discuss
Use “required” for noise or intelligibility problems, “preferred” for taste-based changes, and “discuss” for items where you want to choose the method together. If everything is top priority, it becomes difficult to resolve conflicting requests.
Review a version with the required items fixed first. You may find that some preferred changes are no longer necessary, reducing the number of revision rounds.
Explain which part of a reference track matters
A reference URL alone does not reveal whether you mean the low end, vocal, width, or loudness. Be specific: “bring the vocal this close” or “make the chorus feel as wide as the section at 0:45.”
Different arrangements and keys cannot produce exactly the same sound. Use references to share direction rather than demand matching numbers. See How to Analyze a Reference Track in Your DAW for a practical comparison workflow.
Combine feedback from multiple people into one list
If each member sends notes separately, requests such as “turn up the vocal” and “turn up the backing track” may arrive at the same time. Have one representative remove duplicates, resolve contradictions, and send a single agreed list.
When opinions remain divided, export short A/B versions and decide after comparing them instead of forcing an abstract conclusion.
Limit each revision round and record the changes
Changing 20 items at once makes it hard to know what improved the mix or caused a side effect. Group the work into lead balance, low end, space, and details.
The engineer can reply with notes such as “1:24: raised the vocal by about 1 dB and shortened the delay,” while also recording skipped items or alternatives. Keep resolved items in the next list and mark them complete.
Define the conditions for final approval
Agree on the release date, number of revision rounds, playback systems used for review, and final decision-maker in advance. Without a deadline, small preference changes can continue indefinitely.
For final decisions, see How to Know When a Song Is Finished. For production handoff, see How to Prepare a DAW Project for Collaboration. Clear feedback depends less on technical vocabulary than on having the version, time, target, desired result, and priority in every note.
