View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001462KdenliveEffectspublic2010-02-26 12:362011-06-10 10:50
Assigned Tottill 
Platformx86_64OSOpenSUSEOS Version11.2
Product Version0.7.7 
Target VersionFixed in Version0.8 
Summary0001462: No choice between keyframability and non-keyframability of effects
DescriptionThere should be a chance for the user to choose wether she wants a certain effect to be keyframable or not-keyframable, i.e. there the effect's values stay fixed for the entire clip.
TagsNo tags attached.
Build/Install Method(select)
Attached Files

- Relationships

-  Notes
j-b-m (administrator)
2010-02-26 21:14

If you delete the second keyframe, leaving only the first one, it will give you a fixed value for the entire clip.
frostinet (reporter)
2010-02-27 08:06

ah! thx! that helped.

so---where is this documented? i didn't find any official and complete documentation for kdenlive? the application gets more and more complex (in a positive sense), so why isn't there a in depth manual?
thatonefilmguy (reporter)
2010-03-24 13:46

This seems somewhat related to 336, though not directly. Per 336, all effects should be keyframable.

Regarding this issue, when more advanced keyframing is implemented, keyframing should be an 'opt in' process, not opt out. I.e. Effects (aside from transitions) should always be created without keyframes (a static effect), then the user can add keyframes if they wish to animate the effect.

Currently, keyframable FX such as brightness are 'opt out' because they automatically create two keyframes by default.

This should be done across the board to make all effects consistent with one another, although that first requires a more robust keyframing feature as described in 336 to be implemented.
ttill (developer)
2010-11-19 21:45

In 0.7.9 there will be:
1. more effects supporting keyframes
2. all effects static be default and keyframes therefore "opt in" as described by thatonefilmguy
ttill (developer)
2010-11-19 21:47

May I mark this as fixed?
frostinet (reporter)
2010-11-20 10:29

Yes, i think so. This bug can be regarded as fixed. Thanks!

- Issue History
Date Modified Username Field Change
2010-02-26 12:36 frostinet New Issue
2010-02-26 21:14 j-b-m Note Added: 0004763
2010-02-26 21:14 j-b-m Assigned To => j-b-m
2010-02-26 21:14 j-b-m Status new => feedback
2010-02-27 08:06 frostinet Note Added: 0004768
2010-02-27 08:06 frostinet Status feedback => assigned
2010-03-24 13:46 thatonefilmguy Note Added: 0004868
2010-11-19 21:45 ttill Note Added: 0006081
2010-11-19 21:47 ttill Note Added: 0006082
2010-11-19 21:47 ttill Assigned To j-b-m => ttill
2010-11-19 21:47 ttill Status assigned => feedback
2010-11-19 21:47 ttill Fixed in Version => 0.7.9
2010-11-20 10:29 frostinet Note Added: 0006103
2010-11-20 10:29 frostinet Status feedback => assigned
2010-12-11 21:58 ttill Status assigned => resolved
2010-12-11 21:58 ttill Resolution open => fixed
2011-04-26 21:57 j-b-m Fixed in Version 0.7.9 => 0.8
2011-06-10 10:50 Granjow Status resolved => closed

Copyright © 2000 - 2016 MantisBT Team
Powered by Mantis Bugtracker