Bug 365695 - git master: trying to move existing transition keyframes has no visible effect, does not get saved with project
Summary: git master: trying to move existing transition keyframes has no visible effec...
Status: RESOLVED NOT A BUG
Alias: None
Product: kdenlive
Classification: Applications
Component: Effects & Transitions (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR major
Target Milestone: ---
Assignee: Vincent PINON
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-14 18:50 UTC by Wegwerf
Modified: 2016-07-16 14:14 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Wegwerf 2016-07-14 18:50:55 UTC
This is a strange bug. After creating a composite transition with four keyframes for ramp up and ramp down, I now cannot edit these transitions correctly anymore. Trying to move the last two keyframes near and at the end of the transition does correctly move the keyframes in the transition properties frame. However, the underlying MLT model does not correctly get synced, so when playing the transition the dialog shows the edited keyframes, yet the project monitor still shows the old, unchanged keyframes. Moreover, saving and reloading looses all transition keyframe edits; instead, the keyframes get reverted to their original settings.
Comment 1 Wegwerf 2016-07-14 18:52:40 UTC
New info: changing the "track" parameter causes the MLT model to be synched with the properties pane.
Comment 2 Jean-Baptiste Mardelle 2016-07-15 21:23:05 UTC
I cannot reproduce. Does the bug appear everytime on this project ? If yes, can you attach the project here and otherwise do you have an idea of how to reproduce the problem ?
Comment 3 Wegwerf 2016-07-16 14:14:19 UTC
For whatever reason I cannot reproduce this bug with my saved intermediate project files either. So in order to reduce clutter I'm of course closing this bug as INVALID and will watch the scene while editing... At least I now know a possible workaround using the track parameter...