Sometimes the splitting works as expected, with all of the keyframes of the second clip retimed so that they still happen at the same place in the video after being split.
But sometimes the keyframes get duplicated onto both clip without being retimed. Since the start of the second clip is after the split and keyframes are timed relative to the start of the clip, getting an exact copy of the first clip’s keyframes is often undesirable.
I would like to know why I’m getting two different behaviours when splitting clips that have keyframes.
This is the same inconsistent and seemingly unpredictable behavior that I have experienced.
It has been so inconsistent and unpredictable that I have hesitated to report it as a bug; when asked “Is it reproducible?” I would have to say “No”, because I have not been able to determine which exact series of steps leads to the desirable result, and which series of steps leads to the undesirable result.
Let’s use this thread to try to find some steps that reproduce the problem. It is best to start with the bare minimum example if possible. But sometimes that is not possible - for example, maybe it only happens under certain complicated circumstances.
Can either of you suggest the frequency of the failure? Is it 1 out of 2 times or 1 out of 20?
As I wrack my brain trying to remember, I think the worst case was when I was using SPR and Opacity on a PNG image to float the ghost of Nebuchadnezzar around the screen.
It may behave differently on an image than on a video clip.
It happens when the Ripple Twins are used; it is a track that is NOT the one split and dragged, rather, one that was split and brought along by the use of both Ripple Twins.
It appears, so far, that nothing else causes this.
…
…
Oops, I spoke too soon.
Short version:
A clip split by being cuaght in the ripple does NOT have its Keframes split at the split; rather, it now has Keyframes starting at the split point with timings, not from that point, but from the original unsplit beginning of the clip.
If you had a clip with Keyframes at +0 frames, +5 frames, +17 frames, and +51 frames, and it was split at frame 40, you should habe a second frame with a split at frame 11.
That is what you DO get if this is the clip that was split explicitly.
But if that split was from the Ripple Twins, the second clip now has Keyframes at +0 frames, +5 frames, +17 frames, and +51 frames from its own new beginning, which has now correlation now with the video (and audio) content.
I reproduced this just now on an AUDIO track while splitting a VIDEO clip with the Ripple Twins.
The pattern of these Keyframes bears no relationship with the audio.
It is exactly the pattern of the Keyframes in the original, unsplit video, but now reference to the wrong starting frame.
I tried to replicate the problem in an earlier version appimage, but the MLT will not open.
I think I read somewhere that the “Try it in an earlier version appimage” debuging tool was being taken away in the new release. (When “it” is an actual project, as opposed to a conceptual series of steps to be laboriously and identically, hopefully identically, reenacted.)
The previous times I have seen this were in earlier versions, dating nearly back to last Christmas, but I do not remember which numbered SaveAs of which project was where it occurred.
I’m not understanding the use of splitting the clip, and leaving it in place.
If it’s for adding another filter to the same clip, wouldn’t it just be easier to trim the filter, instead of splitting?
If one splits a clip. with the intention of moving it, and immediately after the split discovers that it is ruined, why proceed to move a ruined clip-fragment?
Post #7 was not “I tried to make a video and this stopped me”, it was deliberate search for circumstances in which the Keyframes did not behave in their usual way upon a split. So the particular procedure may have been a bit odd.
I am beginning to think that the problem reproduced in Post #7 and the problem reproduced in posts #8 & #9 are NOT the same problem.
I think I read somewhere (and I could be mistaken) that Keyframes and fades shared some of the same resources. If that is so, the post #7 problem would have an explanation unrelated to posts #8 & #9.
Also, if that is the case, I would hope that the pursuit of that issue would not obscure the issue of what happens when Ripple is used, splitting and moving another track.
I was able to reproduce the problem in an earlier version, by using the same clips and the same sequence of steps (but not the same project file, its a 5.01 thing…)
Note that the pattern of the Keyframed Gain is preserved in its entirety, now reference to the new beginning of the split-by-ripple clip, instead of referenced to the original mark in the audio.
What makes it seem a random occurrence is that the Keyframes are properly split and referenced when the split is directly upon the Keyframed clip. Since I usually use a single, full length audio track, Keyframed for “gain riding”, as the reference track for each of my videos, and use that as the selected track when I open the video up to insert branding and titles, Shotcut would usually handle the Ripple-split correctly. It was only when I split and dragged a different track, such as when i had two audio tracks instead of one, that all of the Keyframed gain-riding would be lost by the Ripple-split.
