View Issue Details

IDProjectCategoryView StatusLast Update
0000088Cinelerra-GG[All Projects] Bugpublic2019-01-31 23:12
ReporterIgorBeg Assigned ToPhyllisSmith  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionno change required 
Platformx64OSLinux-UbuntuStudioOS Version16.04
Product Version 
Target VersionFixed in Version 
Summary0000088: Timeline: Move/Copy clip with effects and keyframes
Description If a Move or Copy action is done when an effect covers the full video track, and there are keyframes, the values of the last keyframe (on its left) are not saved on that.

In all two mode "Drag and drop... mode" and "Cut and paste... mode".

Added screencast "Timeline_CopyMove-EffectsKeyframes.ogv"
https://streamable.com/4fetb
or
file source: https://www.datafilehost.com/d/7035daae

PS:
@PhyllisSmith: about 0000087, If you mark it as resolved I can not more "say" to you, thanks. Then I do it, here. Thank you!
Steps To Reproduce1) An effect covers the full video track, and there are keyframes.
2) Move/Copy a clip
The values of the last keyframe (on its left, in source track ) are not saved on the destination.
Additional Informationcinelerra-5.1-ub16-x86_64-static - built: Dec 27 2018 22:03:43
(Thank you for the built)
TagsNo tags attached.

Activities

PhyllisSmith

PhyllisSmith

2019-01-30 16:53

manager   ~0000716

Last edited: 2019-01-30 17:10

View 2 revisions

@IgorB: gg had time to look at this today and the code is working as designed. It is all about the default keyframe which is what you see copied on the left when you move. If you have a recommendation for "real life usage" that results in improved operation, please pass it along. I will mark this closed in a couple of days otherwise.

After further inspection, gg now says he "default keyframe" is in the EDL and takes precedence. He does not think it should be changed now.

PhyllisSmith

PhyllisSmith

2019-01-21 15:27

manager   ~0000649

I have not have the chance to ask gg for sure about this yet so I will assign it to me and try to get his attention today or tomorrow.
IgorBeg

IgorBeg

2019-01-21 12:14

reporter   ~0000646

If you want to close that issue, it's okay for me. Thanks.
IgorBeg

IgorBeg

2018-12-30 14:58

reporter   ~0000449

Sorry for my bad English, I had to write:
on the that specific case (screencast), I would have expected that NO keyframe is moved/copied on destination but that "reading" the last value of plugin's keyframes (Color3way) by source, it was copied to plugin destination (without keyframe).
But you (Sam) had already understood well. Thanks.
Sam

Sam

2018-12-30 14:45

administrator   ~0000448

You explained it well Igor. I just wanted to say that this current behavior from the technical side makes sense. The question is whether the last keyframe can be copied automatically when you move it, whether it is technically feasible, so that it is more user-friendly and works as you expect it to. It would certainly be an improvement.
IgorBeg

IgorBeg

2018-12-30 14:37

reporter   ~0000447

From my screencast-test, I would have expected that any keyframe is moved/copied on destination but that "reading" the last value of plugin's keyframes (Color3way) by source, it was copied to plugin destination (without keyframe). Maybe I am explaining bad.

However, it also occur in the "old" Cinelerra-GG version--> Ub16 built: Nov 29 2018
Sam

Sam

2018-12-30 14:13

administrator   ~0000446

I confirm this behavior.

However, I'm not sure if this is a bug or the logical consequence of the functionality.
As soon as you drag the clip into the first track, the keyframe that defines the change is missing, the keyframe stays in the second track. In the first track the plugin is without any changes, no keyframe no changes, it's as if you dragged this plugin from the resource window. This is because the plugins are track related and not clip related. In order for it to have the same information as in the second track, you would have to copy that one keyframe with it and place it on the first track, then you would have the same result. I don't know if it could be automated, if it would be technically feasible.

Issue History

Date Modified Username Field Change
2018-12-30 13:45 IgorBeg New Issue
2018-12-30 14:13 Sam Note Added: 0000446
2018-12-30 14:37 IgorBeg Note Added: 0000447
2018-12-30 14:45 Sam Note Added: 0000448
2018-12-30 14:58 IgorBeg Note Added: 0000449
2019-01-21 12:14 IgorBeg Note Added: 0000646
2019-01-21 15:27 PhyllisSmith Note Added: 0000649
2019-01-21 15:28 PhyllisSmith Assigned To => PhyllisSmith
2019-01-21 15:28 PhyllisSmith Status new => assigned
2019-01-30 16:53 PhyllisSmith Note Added: 0000716
2019-01-30 17:10 PhyllisSmith Note Edited: 0000716 View Revisions
2019-01-31 23:12 PhyllisSmith Status assigned => closed
2019-01-31 23:12 PhyllisSmith Resolution open => no change required