mix.instrument only read `plugin` and `track` and ignored every other field, so a
synth setting written beside `plugin` (cutoff, amp_sustain, level…) came back
as success and the render never changed.
It now takes the built-in instrument's parameters in `params`, validated before
anything is changed (unknown ids and non-numbers are errors, values are
clamped into range), and refuses any other field with a message that points to
`params` and mix.instrument_param.
It cut the new clip at MAX_RENDER_SAMPLES / channels without a word, after
allocating up to 2 GiB for it. Refuse such a selection up front, as #326
does for other renders, before anything is generated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
recording.json names the take files whose headers recovery rewrites. Before
writing, check that each is a regular file (not a symlink) directly in the
Audio Files folder a recording of that session writes into (next to the
session file, or in its folder under the autosave root) and that it starts
with the float WAV header the recorder writes. Anything else is left
untouched, logged and listed with the media recovery couldn't load.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
clip.unloop found loop copies only by comparing content of back-to-back
clips. As soon as the source clip's notes were edited, its content no
longer matched the copies and unloop answered "the selection is not a
looped clip" for the very loop that clip.loop had just created.
clip.loop now tags the origin and its copies with a shared `loop_id`
(new optional Clip field, serde default so old sessions load), and
unloop treats equal-length adjacent clips with the same loop_id as one
loop. The content comparison stays as a fallback for loops without a
tag. unloop with mode=flatten clears the tag so the copies become
ordinary independent clips.
Propagating edits from the source to the copies is not part of this
change.
Tab found the next transient only on the first selected track, analysed
everything from the cursor to the end of the track on every press, and
Alt+Tab, Shift+Tab and Alt+Shift+Tab ignored Tab to Transient (Shift+Tab
did nothing at all). The toolbar button used the Selector tool's icon.
- A new command, edit.tab {back?, extend?}, does what the Tab keys do, as in
Pro Tools: Tab and Alt+Tab (Option+Tab on a Mac, Ctrl+Tab on Windows and
Linux) move the insertion point to the next or previous clip start, end or
sync point on the selected tracks; Shift+Tab and Alt+Shift+Tab
(Ctrl+Shift+Tab) extend the selection. Alt+Shift+Tab pulls the selection
end back while a stop lies inside the selection, then grows its start.
- With Tab to Transient on, the stops also include the transients on every
selected audio track and the note-ons and note-offs on MIDI and Instrument
tracks. A transient within 10 ms of a clip boundary or note is that stop,
not a second one.
- Transients are detected in fixed 10-second blocks of each clip, so Tab and
Alt+Tab always find the same ones and a long clip costs one block per
press. Analysed blocks are cached while their clips, clip effects and audio
are unchanged: 0.5 ms a press across the demo's five audio tracks, 43 ms
without the cache.
- The Tab to Transient button gets its own icon, an arrow into a transient.
Cmd+Alt+Tab still toggles Tab to Transient. On Windows and Linux the desktop
takes Ctrl+Alt+Tab, and Pro Tools' Ctrl+Alt+T is Thin Automation here too, so
the button and the Options menu are the way there.
Bounce Mix rendered the whole file inside one UI frame: the window stopped
drawing and nothing could cancel the bounce until the file was written,
which takes minutes for long or plugin-heavy sessions.
- engine: io::Bounce renders a slice at a time (step) and reports its
progress; dropping an unfinished one cancels it, removing the partial
file and keeping any older one. cmd::bounce_job builds it from
file.bounce_mix's params; the command and stems still run it to
completion.
- ui: the Bounce dialog starts the job and logic() renders it for 30 ms
per call (32 blocks in the browser, where Instant panics), requesting
another call each time, so it carries on while the window is hidden
(eframe then runs logic alone). A modal shows the file, a progress bar
and Cancel (or Esc); the status line reports the result, and the Task
Manager lists the running bounce.
- It stays on the UI thread because hosted plugins must be created there.
A bounce rendered the whole mix (or bus) into memory and then encoded a
second copy, and the render silently stopped at 2^29 samples: about 93
minutes of stereo at 48 kHz, 31 of 5.1, 15 of 7.1.4. Longer bounces came
out cut short while file.bounce_mix still reported the requested length.
- audio-io: FileEncoder writes WAV/BWF (RF64 above 4 GiB), AIFF and FLAC
block by block into any Write + Seek, byte for byte what encode writes
for the whole buffer. check_room fails up front when an AIFF (4 GiB) or
a FLAC (2^36 frames) can't hold the bounce. AIFF and FLAC encode run on
the same writers; their output is unchanged.
- mix: RangeRender renders the main mix or one bus over a range of any
length, a block at a time; render_range and render_bus (in memory,
still capped) are built on it.
- engine: io::Bounce streams the main mix or a bus, or its stereo
fold-down, into "<name>.part" next to the target, syncs it and renames
it into place, so a failed bounce leaves no partial file and keeps the
old one. In the browser it encodes into memory (failing instead of
aborting when memory runs out) and delivers the file as before.
Normalize renders twice (peak, then the scaled write); levels are
measured as blocks are written. Stems stream the same way and share the
4-hour limit.
A 100-minute bounce of the demo session now writes all 288,000,000
frames with 83 MB peak memory.
Pro Tools draws a take's waveform as it records; ours showed nothing
until Stop. Each record-enabled track now shows its take growing as a
red clip with its waveform, drawn from the take's live summary through
the same column grid and channel bands as clips (Peak view, as Pro Tools
always shows while recording).
- The take writer keeps, per take channel, the (min, max) of every 128
frames it writes (at most 2^22 blocks, three hours at 48 kHz; the file
records on regardless). Recorder::live_take hands the Edit window what
a track's take holds so far, while the writer runs. The blocks sit
behind a mutex the writer thread and the UI lock briefly; the input
callback is untouched.
- io::live_span places the take as Stop will: from the record start,
only the pass under way when loop recording, and within the punch
range.
Tests: the take writer's summary (record.rs), live_span with loop and
punch (io.rs) and draw_live (tests/waveform.rs).
Brandon Thomas