craft-libs#169 is merged, so the fork pin is no longer needed. Pinned to
storytold/craft-libs 82a24b006eefa036b43c09a67fb9a3fbd17ffe63 (main after the merge) rather than the older 12281d07,
which predates resolve_absolute and the Windows colon refusal.
decode_frame_into refuses a frame header larger than the movie picture
limit before sizing any plane, and Movie refuses a ProRes frame whose
header size differs from the track's declared size before decoding it.
Audio source and movie paths stored in a .scraft session go through
io::stored_path (craft-docpath) before they reach the file system: a
relative path is taken from the session's folder, and paths on other
computers, devices and URLs are refused. A refused source is reported
as missing with the reason; a refused movie is marked offline and the
Video track and Video window show why instead of opening it. Import
Session Data and crash recovery resolve the same way.
`cargo xtask ci` failed on Windows before any test ran: the `windows_ignores_case_and_refuses_devices` test moved `upper` into `check` and borrowed it afterwards for the assertion message (E0382), and the recovery test's `paths` is only mutated inside its `#[cfg(unix)]` symlink block, so `-D warnings` rejected the `mut` everywhere else. Neither test is compiled on macOS or Linux, which is why CI never saw them.
With this, `cargo xtask ci` passes on Windows 11 (MSVC, Rust 1.99).
Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
Found while testing crates/engine/src/cmd/track_more.rs:370-392 (write_rtp); playback side: crates/mix/src/lib.rs:1526-1527
Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Found while testing crates/engine/src/cmd/event.rs:338 (edit_marker; params doc at line 97)
Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Found while testing crates/engine/src/cmd/event_more.rs:416-445
Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Found while testing crates/engine/src/cmd/event_more.rs:753
Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Found while testing crates/engine/src/cmd/midi.rs:129-130
Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The FreeBSD CI VM has no fonts installed, so the "bold" family falls back
to egui's built-in regular face. SENDS A-E and SENDS F-J then measure 47
and 45 pt, inside the 48 pt the measured-fit check allows, so narrow
strips showed them in full next to I A-E and INST, and
mix_narrow_headers failed on FreeBSD.
Narrow strips now always use Pro Tools' short names, whatever the font;
normal strips still shorten a name only when it doesn't fit. A new test
renders the narrow Mix with egui's built-in fonts only, reproducing the
FreeBSD failure on any platform.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Picking a plugin for an insert slot added it but opened nothing, so
every new plugin took an extra click on its slot. As in other DAWs, the
pick now opens it: a hosted plugin's own editor, else its plugin
window (built-in plugins, no audio engine, or an editor that can't open
here, such as CLAP plugins with only an embedded editor on macOS).
The insert menu's picks go through pick_insert, which remembers the
slot when mix.insert succeeds; SoundApp::open_inserted opens it on the
next logic pass, once the audio engine has the instance. Only the menu
opens it, so mix.insert from the CLI, MCP or control channel still
opens nothing. It covers empty and filled slots, in the Mix window and
the Edit window's Inserts column.
Tests: tests/open_on_insert.rs (empty slot, search and Enter,
replacing, Edit window column). menu_search closes the windows the
picks now open before it looks for the menu's Bypass.
Reject oversized batches before any side effects instead of reporting success after truncating calls.
Closes#460
Co-Authored-By: OpenAI Codex <noreply@openai.com>