The score stays editable before audio rendering
YuE2 accepts lyrics and a style prompt, writes a melody-and-chord plan in ABC notation, and turns that plan into vocals plus accompaniment. Its Python interface exposes four stages: planning, semantic generation, synthesis, and decoding. You can save the plan, alter notes or harmony, check selected musical invariants with the included helper, and render a new recording. This is a more inspectable workflow than a prompt box that returns only an audio file.
The repository is small beside its installed environment. Our checkout contained 76 files and about 6,923 lines of source, occupying 1.6 MB before dependencies. Saved runs can retain the score, semantic tokens, acoustic latents, configuration, timings, model identities, and integrity records. Those artifacts make comparisons easier to audit, especially when a seeded result may still vary across GPUs, runtime versions, or model revisions.
A score edit creates a new recording, not a waveform patch
The editing guide includes a bounded harmony example: preserve melody, timing, meter, and tempo while replacing chord symbols, then render both versions and listen. The comparison helper understands the project's limited ABC dialect. Unsupported notation may need conversion, and a helper rejection does not prove the music itself is wrong. This is useful discipline for agent-assisted edits because it checks the requested constraint before another expensive render.
Each edit still generates a full recording. YuE2 does not promise to preserve the original singing voice, timbre, or waveform outside the changed passage. That matters when the 7,073 MB Python environment sits upstream of a review loop that may produce many versions. Keep every output in a fresh directory and compare complete songs. Anyone seeking the equivalent of changing one region in a DAW will find this approach too coarse.
What happened when we ran it
Our sandbox installed YuE at commit 88da114 in 109 seconds. Pip brought in 77 packages, and the environment occupied 7,073 MB before any model-weight storage is counted. The build completed successfully in 3 seconds. For a checkout measuring just 1.6 MB, that install footprint is the first operational warning: testing or deploying the code requires far more disk than the repository size suggests.
Pytest failed with exit code 1 after 27 seconds. It reported 90 passed, 2 failed, and 6 collection or setup errors out of 98, plus 30 passing subtests. Both failed cases were the enabled and disabled variants of test_pipeline_passes_acoustic_callbacks_only_when_enabled; their assertions said a precompile artifact was already registered. Five collection errors showed the same duplicate-artifact message, while test_cuda_graph.py raised KeyError: 'getpwuid(): uid not found: 1000'.
The log establishes those messages, not their root causes. A fresh container should be able to expose hidden assumptions, so we would require a clean rerun before using this commit in a production music service. Pip-audit also found 11 known vulnerabilities. The repository does have a tests directory and one CI workflow, but those signals do not cancel the failed result on our stated 3-CPU, 8 GB Debian sandbox.
The supported path starts with one 24 GB NVIDIA GPU
The generation guide names Linux, Python 3.12, a BF16-capable NVIDIA GPU with 24 GB VRAM, and one request at a time as its starting point. First use downloads model files from Hugging Face. Output is 48 kHz stereo without quantization. The default listening decoder and the decoder used for the published benchmark are different, so the guide tells evaluators to choose explicitly and decode the same cached latents when comparing them.
Our 109-second install did not measure song latency or listening quality, and neither the 3-second build nor 90 passing tests substitutes for a GPU generation run. Storage planning must include model and VAE files beyond the measured 7,073 MB. Pin revisions, record truncation flags, and retain failed outputs. A playable audio file can still reflect a token limit, so listening and artifact inspection belong in the acceptance step.
Covers require a second model environment
The cover workflow uses SheetSage2 to transcribe a source recording into a melody score, then asks YuE2 to make a new interpretation with different lyrics or style. SheetSage2 runs in a separate environment and loads its MERT2 encoder. That makes covers a multi-model pipeline with more downloads and another place to pin versions. The melody-only mode gives accompaniment room to change, while a full score carries chords into the new rendering.
Two open issues define useful adoption limits. Issue 165 asks for the semantic audio tokenizer needed to create YuE2's expected fine-tuning targets; the released VAE encoder produces different latents. Issue 172 reports unwanted vocals in an instrumental request. Neither issue proves a universal failure, but both describe requirements that need confirmation. With 11 combined open issues and pull requests on September 12, the queue was small enough to inspect individually.
Fresh activity does not erase the failed suite
GitHub recorded 7,081 stars and a last push on September 11, 2026. The latest release, yue2-v0.1.6, appeared on September 9. Current pull requests cover progress callbacks, Windows text encoding, lower-memory operation, and ROCm handling, which shows active work around real deployment paths. The project is moving quickly, and buyers should pin a commit rather than assume a short install command always selects the same behavior.
The 11 audit findings and failed 98-test run keep YuE2 in trial territory for us, despite its strong documentation and active issue queue. Its clearest advantage is concrete: the composition exists as a file you can inspect before spending another render on it. If that file is central to your workflow and the noncommercial weight license fits, YuE2 deserves a controlled GPU evaluation. If you mainly want fast prompt-to-song output, the hardware and maintenance cost are harder to justify.