[marcin-koziol]

Problem

After a while some audio tracks started late: the first seconds of a clip were silent, and the track's meter showed nothing either. MIDI tracks were fine.

The cause was self-freeze. Once the load had been high for a while, a track was rendered to a disk cache on fresh plugin instances, and the engine then played that cache. The rendering started immediately and ran faster than real time. TONE3000, a NAM amp, queues its models for loading after its state is restored and plays silence until they are ready (its log says "queued for load", then "NAM model prepared"). So the cache came out silent at its start. For a guitar track, the cache starts exactly at the clip, and its first 2.29 s are digital silence, while the take itself has sound from its first frame. Bounces lose a plugin's first notes the same way when they start close to them.

Change

• New PluginInstance::third_party(). It defaults to false; CLAP, VST3, LV2, AU and sandboxed instances return true.
• When OfflineRenderer hosts a third-party plugin, it now warms up before the first block: WARM_UP_SECONDS (2 s) of real time with the transport stopped, feeding blocks of silence at a device's pace. After that it keeps waiting while an instance reports loading(), for 60 s at most. A plugin gives no sign that a model loaded on its own thread is ready, so the warm-up is a fixed time.
• Built-in plugins and test fakes skip the warm-up.
• Self-freeze KEY_VERSION goes to 2, so caches made without the warm-up are not reused.

The cost: every offline render or self-freeze cache with third-party plugins starts 2 s later.

Tests

• New crates/faderframe-engine/tests/offline_warm_up.rs: a plugin that stays silent for its first 300 ms of real time. Without the warm-up, a render of its first quarter second is silent throughout. With it, the render has sound from frame 0.
• cargo test -p faderframe-engine: 404 passed.
• Self-freeze and freeze session tests pass.
• Clippy reports nothing on the changed crates.

🤖 Generated with Claude Code