0050c18623
Thread Beats/Seconds through the editor now that lightningbeam-core is typed. The timeline UI is seconds-domain (pixels_per_second, viewport_start_time, playback_time, drag_offset), while ClipInstance.timeline_start/duration/ loop_before are beats — the compiler flagged every place the two were mixed. Fixes the reported bugs and the whole class behind them: - Recording placement (audio + MIDI + webcam): the new clip's timeline_start was written from playback_time (seconds) into a beats field, so a second recording landed at the wrong time. Now converted via the tempo map. - Drag/move: introduce snapped_move_offset -> Beats (snap in the seconds/pixel domain, express the anchor's movement in beats) and moved_start(); the group clamp, live preview, and commit all use one uniform beats offset instead of adding a seconds delta to a beats position. - Trim/loop drag preview + commit: overlap limits come from the timeline (beats) but trims are content seconds — converted at the boundary. - Drop (asset drag, stage + timeline), paste, duplicate, split-at-playhead: all convert the seconds drop/playhead position to beats before placing. - Stage playback gates + clip-local time remap: compared seconds playback_time against beats timeline_start; now both in seconds. - Piano roll / infopanel / effect export: clip_dur is Seconds; effect and waveform data converted at use. Core API refinement (motivated by the above): find_max_trim_extend_left/right now return Seconds (the content-seconds gap) instead of raw Beats, since every trim caller wants seconds; loop-extend callers convert to beats. Added a beats_to_x() timeline helper. Whole workspace compiles; 299 core tests pass. |
||
|---|---|---|
| .. | ||
| assets | ||
| examples | ||
| src | ||
| Cargo.toml | ||
| PLAN.md | ||
| TOOL_IMPLEMENTATION_PLAN.md | ||
| build.rs | ||