Page MenuHome

Pasted strip doesnt have F-Curve keyframes from the original
Closed, ResolvedPublicBUG

Description

--- Operating System, Graphics card ---
MacOS X 7

--- Blender version with error, and version that worked ---
2.68

--- Short description of error ---
A pasted strip doesnt contains the original F-Curve keyframes.

--- Steps for others to reproduce the error (preferably based on attached .blend file) ---
Create/import some strip. Configure some animation in one or more of its properties (put some keyframes in F-Curve editor). Copy this strip. Paste the strip.

Event Timeline

Yes, confirmed, this is huge. It has been like that for a while now, I thought it might be intended... (which wouldn't make sense but anyway).

Joshua Leung (aligorith) triaged this task as 30 priority.Nov 19 2013, 12:14 AM

What exactly do you mean by "copy this strip" and "paste this strip"? Are these the sequencer strips or something else?

Thats it! Strips in sequencer.

Here is a video of the "copy strip" and "paste strip".

Joshua Leung (aligorith) raised the priority of this task from 30 to 50.Nov 22 2013, 12:52 PM

Ok, I've taken a look into this.

From the user-side

  • Shift-D duplication seems to work well. <--- For now, this is the workaround to this bug
  • Copy/Paste however doesn't

Root Cause
The cause of this bug is that when strips are copied into the copy buffer, they are assigned unique names. A consequence of this however is that these strips get pasted, it is impossible to figure out what the original curve names should have been. Thus, there are no curves copied over.

Complications

  • We cannot disable the "SEQ_DUPE_UNIQUE_NAME" flag in sequencer_copy_exec() -> BKE_sequence_base_dupli_recursive(), as it seems that this is necessary to avoid some other bug T25932. Even if we did disable this, there are several other things that work against us there
  • An alternative may be to make the copy operation make copies of the F-Curves used by copied strips as well. The problem here though is that keeping copies of this info around is a bit messier. Besides, no other area of Blender does this sort of partial copying of F-Curves for their clipboards.

So, for now, more investigations on how to resolve this problem are needed.

Thanks for the detailed explanation algorith!

I already make monthly donations to blender, but how much would I have to donate to get this problem fixed? :P It's killing my workflow, as I do occasional video editing for a local community TV station and I like to work with multiple scenes for separate but related segments, so duplicate isn't an option unfortunately :( Unless you know of another trick I could use...? I really enjoy editing in blender, but I don't get much time to do it, so when I do I hate dealing with technical issues and duplicated effort :(

Anyway, will wait patiently either way, cheers!

slinkeepie

I am in the same situation than you. I too have donated to the project some time ago. I make videos for an internal channel and most of this (if not all) are done in blender vse. This feature would make our work easier and faster.

Blender is an extremelly interesting software for video editing, but it seems that, unfortunatelly, the developers don't want to give much attention to this specific part. By the way, where could I, as a user, not a developer, give some suggestions for the project?

Thanks!

@Joshua Leung (aligorith), this one also looks like it can't be fixed easily?

While Duplicating a strip works in a scene, it doesn't work between scenes.
However:
Once a VSE strip is copied and pasted, you can also 'copy paste the f-curve' as a second step. However the newly copied strip needs to have a target keyframe created before pasting can occur. Also the pasted f-curve doesn't respect strip first frame or timeline offset value.

I have no experience with this specific issue, but I just submitted another problem about the video sequencer. I'm adding my voice to the one of slinkeepie and jonata that Blender is a really cool piece of video editing software, but unfortunately, I haven't been able to get any one publishable piece out of it because of odd technical issues. But I'd like to be able to use it for an internal channel...

Could it be fixed rewriting the copy/past operation to:

  • store references to the selected strip(s)
  • to paste, use the duplicate operator on copied trips and modify their start frame, channel and scene owner when it's needed.

?

Just ran into this bug when trying to write an addon that copies a strip to another scene... not possible to use duplicate for such a task, and there seems to be no way of linking the strips, so it seems I might be stuck until this is fixed...
Would it be possible to give bpy.ops.sequencer.duplicate() the ability to duplicate into another scene maybe?

Just quoting my comment from T71723 here (note that at that time I wasnt aware of the unique-name-issue -- but I am also not sure if this still applies? [my basis test with the patch mentioned there seemed to survive just fine.... probably needs more investigation...])

Would like to take a step back here [excuse the short detour]
Doing this, because I think we could be a little more consistent across blender as a whole.

For duplicating objects, we have Preferences > Editing > Objects > Duplicate Data > Action (amongst others).
So when you duplicate (with Shift+D), you can specify if you want the action to be copied or not.
For copy-pasting objects this is not considered, blender always copies the action.
[this is the first inconsistency, and I would vote for taking the Preferences into account when copy-pasting. This would make it transparent to the user (instead of being hard-coded)]

Now for the sequencer:
When duplicating a strip [Shift+D], it seems we always get new fcurves
For copy-pasting, you never get new fcurves.
(this is another inconsistency, and I would vote to at least create new fcurves -- use SEQ_DUPE_ANIM in sequencer_copy_exec, but really I would also vote for taking above preferences into account, wouldnt this make sense?)

Minimal (at least dupe the anim -- preferences not taken into account)

1
2
3diff --git a/source/blender/editors/space_sequencer/sequencer_edit.c b/source/blender/editors/space_sequencer/sequencer_edit.c
4index 57a0d63c35e..6f0cb005eb7 100644
5--- a/source/blender/editors/space_sequencer/sequencer_edit.c
6+++ b/source/blender/editors/space_sequencer/sequencer_edit.c
7@@ -3367,8 +3367,9 @@ static int sequencer_copy_exec(bContext *C, wmOperator *op)
8 return OPERATOR_CANCELLED;
9 }
10
11+ int dupe_flag = SEQ_DUPE_UNIQUE_NAME | SEQ_DUPE_ANIM;
12 BKE_sequence_base_dupli_recursive(
13- scene, scene, &nseqbase, ed->seqbasep, SEQ_DUPE_UNIQUE_NAME, LIB_ID_CREATE_NO_USER_REFCOUNT);
14+ scene, scene, &nseqbase, ed->seqbasep, dupe_flag, LIB_ID_CREATE_NO_USER_REFCOUNT);
15
16 /* To make sure the copied strips have unique names between each other add
17 * them temporarily to the end of the original seqbase. (bug 25932)

That all being said, not sure if this could really be considered a bug, it is inconsistent/confusing at least.

@Sergey Sharybin (sergey), @Bastien Montagne (mont29), @Richard Antalik (ISS): what do you think?
sidenote: was also voting for taking these preferences into account in D6120: Separate operators (mesh/curve/armature/gpencil): take user preferences into account for duplicating actions...

@Philipp Oeser (lichtwerk) Unfortunately your code does a bit too much. Here is the graph editor after copy+pasting a VSE strip with animated opacity:

@Philipp Oeser (lichtwerk) Unfortunately your code does a bit too much. Here is the graph editor after copy+pasting a VSE strip with animated opacity:

Thx for noting (missed this)... should I be having a second look?

If you want to, please do :)

Here's an idea for using bits of sequence repeatedly: Found out recently that scene input for the sequencer can use either the camera or the inputted scene's sequencer as what is displayed, audio included.

Also, one can make linked copies of a scene and put them in the sequencer to work around the 2.80 disabling of self-scene input disabling (which was probably created to allow the above to work without recursion problems I guess).

Sybren A. Stüvel (sybren) changed the subtype of this task from "Report" to "Known Issue".

Changed this to a Known Issue, as it has been in Blender for so long but hasn't caused any major problems.

Changed this to a Known Issue, as it has been in Blender for so long but hasn't caused any major problems.

Some people don't agree!

Thanks for the detailed explanation algorith!

I already make monthly donations to blender, but how much would I have to donate to get this problem fixed? :P It's killing my workflow, as I do occasional video editing for a local community TV station and I like to work with multiple scenes for separate but related segments, so duplicate isn't an option unfortunately :( Unless you know of another trick I could use...? I really enjoy editing in blender, but I don't get much time to do it, so when I do I hate dealing with technical issues and duplicated effort :(

Anyway, will wait patiently either way, cheers!

@Clint Hobson (Domarius) Even if this is classified as a known issue, we will look into this and do what we can to resolve them.

Current meaning of known issue is:

Known Issues: Documented short-come of existing features.

When I first looked at this code, it looked hard to maintain(not quite readable), proved by prolonged efforts to fix this. To me this means that there is need to review and possibly rewrite that section completely.

So I agree with Known issue classification.

@Wilbur Jaywright (zargulthewizard) I have no idea how that relates to this task.

Just a way so that if someone needed a large strip compilation over and over they could... No wait, scene inputs don't carry the F-Curves either! :||

Richard Antalik (ISS) changed the subtype of this task from "Known Issue" to "Bug".May 6 2020, 2:29 PM