Bug 461215

Summary: At least multiple "Transform" and "Position and Zoom" effects (but assumingly more effects) overwrite each other
Product: [Applications] kdenlive Reporter: Veps <veps>
Component: Video Effects & TransitionsAssignee: Jean-Baptiste Mardelle <jb>
Status: REPORTED ---    
Severity: normal CC: fritzibaby
Priority: NOR    
Version First Reported In: 22.08.1   
Target Milestone: ---   
Platform: Other   
OS: Microsoft Windows   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Veps 2022-10-30 19:16:21 UTC
SUMMARY
Same properties of multiple effects and even compositions overwrite each other.

STEPS TO REPRODUCE
1.  Add "Transform" effect to a clip (maybe add keyframes) and change change X-position value
2.  Add another "Transform" or "Position and Zoom" (maybe add keyframes) and change X -position here too

Example: Lets say effect/compostion A alters X value to 1 and effect/composition B alters """same"""* X value to 2
[* so apparently it is literally the "same" value although it shouldn't be just the same type of value.]

OBSERVED RESULT
Final X  value of the clip will be 2 (=last value).

It renders the ability of stacking the same effect on the same clip useless -- and even cross-effects other effects like:
"Position and Zoom"
"Transform"
"Compose and Transform"
***BUT*** weirdly not "Zoom Pan" for example.

EXPECTED RESULT
Final X value of clip *should* be 3 (additive value) -- or explained in a more graphical/figurative way: effect B should change the location of the resulting clip after effect A got applied.


SOFTWARE/OS VERSIONS
Windows: 7

ADDITIONAL INFORMATION
From a user perspective it is even effecting properties you didn't touch (though I'm aware it doesn't make a difference programmatically). However if you change in the "first" effect also the "Size" value but not in the second effect, it will be re-set as well.
However changing X and leaving Y (= setting it to 0 indirectly) in the second effect has *no* impact  confusingly.
Comment 1 Veps 2022-11-03 22:27:06 UTC
Seems related/"same" bug as in https://bugs.kde.org/show_bug.cgi?id=461388