Platform-specific packages.
Public downloads should be separated by macOS, Windows and Linux. Each file needs a visible version number, release date, checksum and a short note about what Resolve versions were tested.
Support should feel as clean as the sync.
This is the first support and install copy deck for Music Sync. It is intentionally careful: no version, platform, payment, or delivery promise should become public until the product has been tested.
Resolve script workflow
Known limits visible
Payment gated until tested
Support Center
Install
Sync
Export
Support tickets to prevent
Wrong Resolve versionGate
Missing script folderGuide
Weak camera audioExplain
Download confusionTest
Launch confidence
Public after proof
Install Draft
Resolve script location.
The final support page should show the exact Scripts-folder path for each operating system, plus a restart step and a screenshot of the Workspace menu entry.
Open the script before the first job.
Customers should confirm Music Sync opens in Resolve before a deadline shoot. A small sample project should eventually prove the install without needing private footage.
Camera scratch audio still matters.
Quiet playback, blown-out onboard audio, heavy crowd noise, or camera clips without usable scratch audio can reduce confidence or move a clip into review.
It builds a starting timeline, not a finished cut.
The tool should save setup time. It should not pretend to replace editorial taste, performance selection, pacing, story structure, or final music-video rhythm.
Uncertain clips need to stay visible.
Low-confidence clips should be flagged, parked, or moved to a review/b-roll timeline so the editor can decide instead of hunting through a folder again.
Launch Gates
Test real installs before naming versions.
Confirm Resolve, Resolve Studio, Python/script runtime behavior, and platform-specific packaging before publishing compatibility claims.
Payment must deliver the right file.
Ko-fi or Stripe can both work, but only after the purchase flow sends the correct platform download, receipt, license note and support contact.
Support terms need to be simple.
The first public version needs refund, update, license, seat, bug-report and known-limitation language before the buy button is made real.
Support Recommendation
Public support should be blunt and useful.
The tone should feel like a toolmaker, not a SaaS help center: direct install steps, honest limitations, and a fast path to email when something breaks on a real edit.
Use a controlled early-access release until install, sync quality and delivery are proven.
Use a simple KFS-backed support email until the product has its own operating rhythm.