[6uclz1]

What this changes for you

These fixes come from the bug notes taken during the HyperFlip v3 build (bugs.md).

arrangement clip create --notes-* writes the notes into the clip it just created. Live keeps arrangement_clips in start-time order, but the backend picked clips[before_count]. When the new clip started before existing clips, it got no notes and the track's last clip got them instead. This was hit through live-deemute plan --replace. The same lookup had two more consequences:

• audio arrangement clip create set --length on the wrong clip;
• arrangement from-session wrote repeated notes to the wrong clip when cursor positions were not in order.

All three paths now share _created_arrangement_clip_index, which finds the new clip by start_time. If it does not find exactly one clip, it fails with INVALID_ARGUMENT instead of picking a neighbour.

device parameter set-display help says what the value is. The value is a bare number in the display unit: 180 for 180 ms, 2000 for 2.00 s, -6 for -6 dB. Unit text is rejected, and negatives go after --. The README says the same.

Computer Use docs. docs/computer-use/cli-gaps.md now lists the GUI-only step of turning Back to Arrangement off after session capture, with a playbook in ableton-live.md.

Not fixed here (follow-ups)

• device parameters list --device-ref without a track selector. A device ref could carry its track, but that changes the wire protocol for every device command, so it needs its own change.
• A CLI command to turn Back to Arrangement off, so session capture can clean up after itself. It needs a new Remote Script command, verified in a running Live.
• Device rename. This is a feature request.
• Left as is: late session capture starts (already detected and reported, so a retry works), the bar-0 pre-roll limit, the Wavetable unison/wavetable gap (a Live API limit, already documented), and the unwarp length glitch, which was not reproduced on its own.

Public contract impact

This is an intentional change, limited to help text. command_surface_snapshot.json changes only in the set-display VALUE help. Commands, envelopes, exit codes and protocol are unchanged. public_contract_snapshot.json has no diff.

Update after the plugin split

Main moved offline audio analysis (audio loudness / spectrum / reference) into the ableton-cli-analysis plugin (#136). This PR's non-WAV support was in loudness.py / spectrum.py, which no longer exist in core. That part now lives in 6uclz1/ableton-cli-analysis#1. This PR keeps the arrangement clip fix, the set-display help and the Computer Use docs. Core's audio_analysis/io.py is main's version unchanged.

After merging main: full pytest 1523 passed, dev_checks / ruff check / ruff format --check pass, the quality harness reports 0 failures (407 warnings), and generate_skill_docs.py produces no diff.

Verification (original)

• TDD: two new backend tests (MIDI notes and audio length on a clip created before an existing one) fail without the fix and pass with it. The stubs now insert clips in start-time order, like Live.
• dev_checks, ruff check and ruff format --check pass. Full pytest: 1456 passed. The quality harness exits 0 with 0 failures and warnings stay at 416. generate_skill_docs.py produces no diff. The Remote Script runtime check passes.
• Not checked against a running Ableton Live. A manual check would be: create an arrangement MIDI clip with notes before an existing clip, then check which clip got the notes.

🤖 Generated with Claude Code

[6uclz1]

Checked in Live 12 Suite

This is a local, unpushed merge of this branch with #132. I installed its Remote Script and started Live fresh.

MIDI: notes go to the clip just created. On track 0, I created clips out of start-time order. Each had a single note: beat 8 → pitch 72, then beat 0 → 60, then beat 4 → 64. Reading each clip back with arrangement clip notes get:

clip	start	pitches
0	0.0	[60]
1	4.0	[64]
2	8.0	[72]

Before the fix, the beat-0 clip's notes went to the beat-8 clip.

Audio: --length goes to the clip just created. I created a clip from a 3 s WAV at beat 8 with --length 4, then one at beat 0 with --length 2. arrangement clip props get shows end_marker 2.0 on the beat-0 clip and 4.0 on the beat-8 clip, so each write landed on the right clip.

Separate, pre-existing issue (same code on main). Live refuses clip.length on arrangement audio clips, so the backend falls back to end_marker. The clip still covers 8 beats (length 8.0, looping, loop_end 8.0). The command reports this rather than hiding it (length_set: false, end_marker_set: true, requested_length), but --length does not shorten an audio clip in the arrangement. This PR doesn't change that behaviour.

🤖 Generated with Claude Code