Communicating mix notes to an engineer well comes down to three things: one clear goal for the mix, every note anchored to a specific moment in the track, and a single prioritized list the engineer can act on without guessing. Most stalled projects are not caused by bad ears, they are caused by notes that say “make it punchier” with no timestamp, sent against a version nobody is certain about.
The process below takes about 30 minutes for the first round. It is the workflow we still use in 2026 when a mix has to survive a label deadline and three people with opinions.
Before the step-by-step, the short version:
- One goal per mix. Three goals means the engineer picks one for you.
- Every note gets a timestamp and a version.
- Describe the problem and the result you want, not the plugin you think should fix it.
- Label your notes must-fix, should-fix, or optional.
- One channel, one message, no fragments in a second app.
- Approval is a word you write, never a silence you assume.
What You Need
You can send notes with nothing but a voice message, but the ones that come back fast and land right usually start with a few things in place.
The exact version. Write down the full file name you are listening to, including the version number and date. Version confusion is the single most avoidable time sink in a mix revision: notes meant for V2 land on top of V4, and the engineer changes something that was already fixed.
Ten minutes of quiet listening, on more than one system. Start on good speakers, then check headphones and a phone speaker. A vocal that reads clearly on monitors can disappear on a small speaker, and that difference is exactly the kind of problem worth writing a note about.
One or two reference tracks, marked to the second. Do not just send the track. Note the timestamp of the thing you like: “0:58, how the vocal sits against the snare.”
A rough mix or an early bounce. It gives the engineer your starting point and stops both of you describing a mix you were not both hearing.
A written list rather than voice memos. Engineers work through a written list systematically. Voice notes get replayed, half-transcribed, and misremembered.
Context on where the song will be heard. A track played in a club, on a phone, and through earbuds are three different mixes. Say which one you care about, and whether the release date is soft or fixed.
A rough idea of what a mix can change. Balance, tone, dynamics, effects, and space are mix decisions. The arrangement and the performance were decided when the song was recorded, and asking for them mid-mix is how a revision round turns into a re-record.
How to Communicate Mix Notes to an Engineer Step by Step
1. Define the Main Goal
Before you write a single note, write one sentence describing the outcome you want. Not three sentences. One.
Most mix goals fall into four buckets: vocal clarity, emotional impact, translation across playback systems, or matching the character of a reference. Pick the one that matters most for this song. A track with a busy beat and a whispered hook might need clarity. A sparse ballad that should feel enormous on a phone might need impact.
When you send three goals, the engineer chooses one, makes the other two worse, and you discover the tradeoff three rounds later. If you genuinely have two, say which one wins when they conflict. That sentence saves a revision.
2. Separate Feedback Into Categories
Sort your notes into a small number of buckets before you send them. Balance (how the elements sit against each other), tone (how bright, warm, thin or thick things sound), dynamics (how the track breathes and moves), effects (reverb, delay, width, saturation), arrangement (what plays when), performance (how something was played or sung), and technical issues (clicks, noise, a channel that is clearly broken).
Two of those buckets behave differently from the rest. Arrangement and performance notes are not mix notes, they are record notes, and engineers are far more comfortable hearing them at kickoff than three rounds in. Mark them clearly so nobody quietly tries to EQ their way around a missing guitar part.
Technical issues are the opposite case: they are not taste at all, and they should be reported the day you hear them, not at final approval.
3. Describe the Problem and Desired Result
This is where most notes are won or lost, and it is the part that answers the top question engineers get asked: what is the most useful thing a client can send? Not more information, and not more technical information. A specific observation.
Replace the adjective with a moment, a comparison, and a result:
- Instead of “the vocal is buried” — “at 1:12 the synth pad opens up and the lead vocal disappears; I want the vocal to stay in front.”
- Instead of “the chorus needs more energy” — “the second chorus, from 2:38, sits at the same intensity as the verse. I want a lift.”
- Instead of “it feels too loud” — “on headphones the master hits uncomfortably around 0:45 and again at the end. I want to be able to listen for an hour.”
- Instead of “boost the mids at 3k” — “the guitars sound thin and squeaky on the small speaker. I want them fuller.”
- Instead of “add more reverb to the drums” — “the snare sits in one space while the rest of the kit is dry and close. I want them to feel like they are in the same room.”
Chained technical instructions are the failure case engineers complain about most. A note like “3 dB of compression at 2.5:1 on the snare” may not be achievable on a track that has already been bus-processed twice, and chasing the exact figure often makes the mix worse. The problem is the right unit of feedback; the solution is the engineer’s job.
4. Prioritize the Notes
Sort your list into three tiers and label every line.
Must-fix is short. Three items, four at the outside. If you have nine must-fix notes, nothing is prioritized and the engineer will quietly pick the two that take ten minutes.
Should-fix notes are real, and they wait. Optional notes are wishes, and they are fine to lose entirely. Tagging them takes thirty seconds and it does two useful things: it protects your priority items from being buried, and it tells the engineer which lines they can close without asking.
A note the engineer cannot deliver in the current round is a note you did not prioritize. That is the entire test.
5. Use a Time-Stamped Feedback List
Anchor each note to a moment. The format that works, and that engineers ask for constantly, is one line per note:
0:47 | low end | kick and bass blur together when the chorus enters | want the kick to punch through
Four fields, no prose. Timestamp, category, what you hear, what you want. Bar numbers beat timestamps if you count bars, and whole-track notes are fine as long as you say so: “whole track: the vocal sits behind the beat on every hook.”
Pin the notes to the version. Write the file name at the top of the list and the date you listened to it. A producer describing a workflow of stems in a cloud folder with a growing email thread mentioned the version confusion problem directly, and it gets worse every time a new bounce lands on top of the old one.
6. Send Notes With a Reference
A reference track is a compressed instruction. It carries tone, energy, vocal treatment, drum weight, and arrangement in a form no written note can match, and it is worth using.
It also fails constantly on its own, and the failure gets repeated on every forum: artists send a track, hear nothing change, and conclude the engineer ignored them. References fail because the engineer does not know which of the thousands of differences you want. Should the chorus drums be heavier like the reference, or should the vocal sit lower in the mix like the reference? Both are in there and they are opposites.
So pair it. Name the element, give the timestamp, and draw the line:
- “I want the vocal treatment from this track at 1:12, dry and up front.”
- “I want the low end weight of the chorus, not the intro.”
- “Do not copy the width on the guitars. This needs to stay mono-compatible.”
Two or three references, each with a sentence, is plenty. A wall of tracks tells the engineer you have not decided yet.
7. Review the Revision and Ask Focused Questions
When the new version arrives, go back to your must-fix list, not to your memory of the first mix. Work down it line by line and mark each one done, partly done, or not done.
Then ask about the ones that are not done, in the same descriptive form you used before. “At 2:38 the lift still is not there, it sounds identical to the verse” gives the engineer something to work with. “You ignored the energy note” gives them nothing but a bad weekend.
If a revision made things worse, say what regressed rather than asking for a revert. Reverting throws away every other change in the round. Engineers name this as their real fear, that client notes can degrade a mix, and the best thing you can do about it is describe the damage in the same precise language you used for the original note.
One last thing worth knowing. Experienced engineers translate rather than refuse, and the best of them take a note that fights their instincts and find a way to do what you meant. That only works if what you meant was specific. A clear problem gets translated. A vague feeling gets a guess.
Common Mistakes
Most of these come from the same instinct, which is that you should make your notes impossible to misunderstand. The instinct is good. The execution usually creates a revision round instead of preventing one.
Sending contradictory requests in the same round
“Bring the vocal forward” and “let the vocal breathe more” are not opposites, but nobody knows which you want at 0:30. When two notes pull against each other, put the priority in writing: “If these conflict, the vocal forward wins.” It takes one clause.
Treating a reference track as a complete brief
The most common version of this is sending a link and the word “like this.” A reference without a sentence is a mood, and the engineer has to reverse-engineer which part of it you meant. Add the element, the timestamp, and one line on what not to copy.
Vague loudness complaints
“It feels too loud” has no address, no moment and no system. Name the system, the timestamp, and what you want instead. “On headphones the master is fatiguing after the second verse, I want to sit with it for an hour” is a note an engineer can act on immediately.
Everything in round one
Twenty notes in the first round is a wish list, not feedback. The engineer will read it as a verdict on the whole mix and you will get one large, unreviewable revision back. Ship your three must-fix notes, hear the result, then decide what is still wrong with fresh ears.
Presenting a preference as a problem
“The mix is wrong” invites a debate you do not want to have. Say what you heard and how it landed: “the chorus feels flat to me, I want the lift.” If something is a taste call rather than a fault, label it as a preference. Engineers flag preference notes for a reason — treating them as failures is what turns a two-round mix into a five-round one.
Fragmenting feedback across channels and versions
Notes in email, a couple in direct messages, one in a voice note, and a reference link someone else sent. That is the workflow a producer on r/mixingmastering described, and it degrades with every version: the thread nests, the newest note gets lost in the oldest thread, and the engineer ends up guessing which file the last instruction refers to.
The fix is boring and it works. One channel for the project. One message per revision round, titled with the song name and version. One person who sends the notes, even when three people have opinions. If you are a manager, an A&R, or a producer sending notes for an artist, you are that person, and your job includes reconciling conflicting feedback before it reaches the engineer rather than passing both versions along.
And say the word out loud when you are happy. Silence is not approval. Send a line that says you are approving the mix, what is being approved, and the date. It closes the round and it stops a revision nobody asked for from starting quietly in the next email thread.
Frequently Asked Questions
How detailed should mix notes be?
Detailed enough that the engineer can hear the problem in their head without playing the session twice. One timestamp, what you hear, and what you want instead is enough for most notes. Add a second sentence only when the note needs a comparison or a boundary, such as matching a reference at a specific moment. Length is not the measure: clarity is. A short precise note beats a long emotional one every time.
Should mix notes be technical?
Use technical language only when it describes the problem rather than prescribing the fix. Terms like masking, sibilance, low end, dynamics, width, or translation describe what you are hearing, and engineers use them constantly. Specific settings are risky: a compression ratio or a frequency boost may be unreachable on an already bus-processed track, and chasing the figure can make the mix worse. Describe the symptom, let the engineer choose the session move.
How many mix revisions should I get?
Two full revision rounds plus one final print check is a fair standard, and it is worth agreeing on before the work starts rather than after. What matters more than the number is the scope rule: rounds cover changes to the existing mix, while anything that requires re-recording, new arrangement, or a different song is a new production request. Define that line in writing at kickoff, because it is the difference between a project that finishes and one that never stabilizes.
Can I send a mix engineer a reference track?
Yes, and it is one of the most useful things you can send. A reference carries tone, energy, and treatment in a way words cannot. It works best when you name the element you are borrowing, give the timestamp of the moment you like, and state what you do not want copied. Artists report repeatedly that references alone seem to do nothing, and the reason is almost always that nobody told the engineer which of the thousands of differences you were pointing at.
What do I do if I disagree with my mixing engineer’s choices?
Say so directly, but describe what you are hearing rather than what setting you think should change. If a decision misses the mark, point at the timestamp, describe the effect on you, and name the result you want instead. Engineers accept this routinely, and experienced ones often do the opposite of their instinct to deliver what you meant. What slows things down is repeated vague objections, which force a rebuild instead of a fix.
What should I include when sending notes for the first time?
Include the exact version you listened to with its date, your one main goal for the mix, and the notes sorted into must-fix, should-fix, and optional. Every note needs a timestamp and a one-line description of the problem and the desired result. Add any references with the element and timestamp called out, and note which playback systems you care about. That is the whole list. The point is that an engineer can act on it without replying with questions.
Conclusion
Start with one action, not a better process. Write your main goal in a single sentence, pick the three notes that would matter most if they were fixed, and put each one into the format: timestamp, what you hear, what you want instead. Attach one reference track with the element and moment called out, title the message with the song name and the version you listened to, and send it in the one place you and the engineer already use.
That is the whole method. Send it in 2026, listen to what comes back, and work down the same list again rather than starting a new critique from scratch.
