Week 9 & 10: Speed Ramp Implementation, MR Opened

Wait 5 sec.

This is a weekly update from my Google Summer of Code 2026 project with KDE, improving effect widgets in Kdenlive, a free and open source video editor. Combining two weeks here since the last post covered a lot of ground already.From research to implementationFollowing up from the last post, moved from investigating Speed Ramp to actually building it. The plan confirmed with Jean-Baptiste: reuse Kdenlive's existing keyframe type system rather than free bezier handles, and use KeyframeCurveEditor's per-pixel MLT sampling pattern as the reference for drawing the curve inside RemapView.ImplementationFour commits, each built clean before the next:Added per-keyframe type storage (m_keyframeTypes), keyed by output position alongside the existing keyframe map. Absent key means linear, so existing projects load unchanged with no migration stepSwitched serialization and parsing to MLT's own animation API (anim_set with a keyframe type, then serialize_cut), instead of hand-formatted strings, so the type suffix always lands on the correct keyframeAdded the curve band itself: sampled per pixel from the parsed time_map animation and drawn between the existing input and output rulers. What's drawn is exactly what MLT will play back, not an approximationAdded a Type selector in the remap dialog, starting with a curated list (Linear, Smooth, Cubic In, Cubic Out)TypeTypeKeyframe types follow their keyframes through drags, clip resizes, and deletion, and are captured in undo/redo alongside keyframe positions.The curated list, and whyThe full MLT keyframe type list also includes Bounce, Elastic, Exponential, and Circular, all of which overshoot outside the 0..1 range. On a time map, an overshoot means source time briefly runs backward, so the clip plays in reverse for a few frames at the keyframe boundary. That could be a real effect some people want, or a confusing artifact for everyone else. Left it out of the curated list for now and flagged it as an open question in the MR rather than deciding alone.Manually verifiedExisting projects with time remapping load with all keyframes linear, playback unchangedSetting a keyframe to Smooth, Cubic In, or Cubic Out changes the curve shape and is audible/visible in playbackUndo/redo through type changes restores both type and curve correctly, no desyncTypes survive keyframe drags, clip resizes, and neighbor deletionSave/reload preserves types; linear-only projects round-trip without gaining type propertiesMR openedOpened MR !928, referencing #2188 and #1454. Pipeline is running. No unit tests added this round since RemapView holds state directly in the widget, not reachable from the existing test harness without splitting the storage out first, noted this directly in the MR rather than skipping silently.What's nextWaiting on Jean-Baptiste's review, specifically his call on the curated type list question.