MixPass is our own music collaboration product, currently in beta. It gives a song a review room with audio passes, change notes, timestamped feedback, conversation, and approvals. The room keeps the next decision close to the work it describes.
The file arrives. The context does not.
A producer shares a new mix. The artist listens later and sends a message about the vocal in the second chorus. Someone else responds to an older file. A revised mix arrives, but the conversation still contains comments about the previous one. Before the producer can make another change, they have to reconstruct which file each person heard and which notes still matter.
That is the problem MixPass is designed around. Sending audio is only one step. The rest of the job is preserving context through repeated listening, discussion, revisions, and sign-off. A folder can hold all the files while leaving that coordination work to the people using it.
We built MixPass as our own product. This story describes its design and implemented workflow; we have not measured a reduction in revision time or established a customer outcome.
Give each song a room, and each revision a pass
The song room is the stable place collaborators return to. Inside it, each audio upload becomes a separate pass with a label and notes about what changed. That distinction matters: the room represents the ongoing project, while the pass represents the exact work someone is reviewing.
In the public sample, Soft Signals has Demo 01, Mix 03, and Mix 04. Opening version history shows the passes together with their filenames and change notes. A collaborator can audition an earlier pass or choose another for A/B comparison. The sample illustrates the interaction; its project history is fictional.
The useful design choice is to preserve earlier work rather than make the latest upload stand in for the whole project. It adds version management to the interface, but gives someone a way to check a previous idea and understand a new revision.
A comment needs a place to land
Feedback about a moment in the song can be attached to a timestamp or time range. The player displays markers, and selecting one opens the note. In the sample room, a vocal comment sits at 01:18 and a bridge note spans 02:31 to 02:45. The recipient can return to the relevant part without translating a message into a location in the audio.
Not every comment needs a timestamp. MixPass also has general notes for a pass, room conversation, and session notes. These serve different jobs: a precise revision belongs beside the audio, a broader observation belongs with the pass, and an ongoing discussion belongs with the room.
That separation asks the interface to do more than display a comment box. It has to preserve what the comment refers to. The benefit is a clearer path from a response back to the work; the tradeoff is giving people several feedback surfaces and making their purposes understandable.
Make feedback actionable without making it disappear
MixPass supports resolving feedback notes and keeping session tasks in a punch list. A note can therefore carry both the requested change and whether someone has dealt with it. The source also supports filtering pending and resolved work, and copying the punch list for use alongside a music production session.
Resolution is separate from deletion and from approval. Finishing a requested adjustment does not establish that every collaborator accepts the resulting mix. Keeping those states separate preserves the difference between doing the work and agreeing that it is finished.
The current public sample’s punch list opens with no items even though its listening screen contains illustrative notes. We verified the task and resolution behavior in the implementation, but the sample is not an end-to-end demonstration of that handoff. That gap matters when evaluating the product.
Listening is not approval
A play count cannot tell a producer that the artist has signed off. MixPass has an explicit approval control, and its review records belong to a particular audio pass. The connector reports pending, reviewed, and approved states for that selected pass.
When a new pass arrives, approval of an earlier pass does not establish approval of the revision. This is a small distinction with consequences throughout the product: version history, review status, and release readiness all need to agree about which pass they refer to.
It also defines a limit for automation. Software can collect recorded approvals and highlight missing ones. It cannot infer artistic agreement from listening activity or from a friendly message in the conversation.
A finished file still needs a trustworthy handoff
MixPass separates working files from the Deliverables Vault, where owners can organize masters, alternate versions, stems, and archives. The public product overview describes auditioning and downloading finished assets from that vault. The implementation also lets rooms sit inside releases and artist lounges, so song-level work can be grouped into a larger project.
The separation reflects two different needs: collaborators exchange material while a song is changing, then need a dependable place to find the finished assets. Treating every upload as an official delivery would blur that distinction.
There is a remaining limit. The connector’s release-readiness check can find deliverable records, but those records do not establish which audio pass produced the files. It reports that relationship as unknown. A file being present is therefore insufficient evidence that it matches the approved mix. Closing that gap would require an explicit link between the reviewed pass and the delivered asset.
Give an assistant facts before asking it for a summary
MixPass has a connected tool interface for reading rooms, review status, punch lists, and release readiness. That gives an assistant specific records to work from when someone asks what still needs attention, rather than relying on a pasted conversation or a vague description of the project.
The important decisions stay in ordinary software rules. Review status comes from explicit records. Readiness checks distinguish complete, incomplete, unknown, and not applicable. A readiness report does not publish or distribute a release.
This is the AI integration pattern the product demonstrates: let software establish facts and permission boundaries, then let an assistant help someone navigate or summarize them. We are not claiming that AI judges the sound, approves a mix, or has improved a business metric.
What the beta establishes, and what it leaves open
The public beta and sample show the core review interface: a song room, multiple passes, change notes, feedback markers, conversation, and an approval control. Source review confirms version-scoped review records, task resolution, deliverable organization, and the connector’s explicit readiness checks.
These are evidence of product and implementation decisions. They do not establish adoption, customer satisfaction, or time saved. The sample does not verify every live authenticated workflow, and its punch-list gap is still visible. Native mobile code exists separately, but this story documents the web experience and makes no app-store availability claim.
For a custom application, the useful starting point is the same: follow the work through a complete loop, including revisions, permissions, exceptions, and the final handoff. MixPass gives us a concrete example to discuss when those needs appear in your project.
Where this fits a custom software project
The music context is specific. The underlying job is familiar: several people review changing work, request revisions, and decide which version is ready. For your project, we would start with one real example of that loop.
- The work
- What people review: a document, design, recording, application, or other changing artifact.
- The response
- Where feedback belongs, who can act on it, and how someone returns to the original context.
- The decision
- Who can approve a particular version and what must be checked again after a revision.
- The handoff
- What the next person receives, and how you establish that it is the version everyone agreed on.
See the product for yourself.
We checked the public product pages and the implementation behind the workflows on October 10, 2026. These links let you explore the public experience.