Pasted strip doesnt have F-Curve keyframes from the original #36263

%%%--- 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.

%%%

Changed status to: 'Open'

#73891 was marked as duplicate of this issue

#65272 was marked as duplicate of this issue

#68160 was marked as duplicate of this issue

#71723 was marked as duplicate of this issue

#40019 was marked as duplicate of this issue

%%%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).%%%

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

Yep, VSE strips...!

Thats it! Strips in sequencer.

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

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 #25932. 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!

Added subscriber: @BenoitROUSSELLE

◀ Merged tasks: #40019.

Added subscriber: @Kunda

Added subscriber: @JulianEisel

@JoshuaLeung, this one also looks like it can't be fixed easily?

Added subscriber: @davidmcsween

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.

Added subscriber: @Natwhipu

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...

Added subscriber: @PauloJoseOliveiraAmaro

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.
?

Added subscriber: @snuq

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?

Added subscribers: @Domarius-1, @lichtwerk, @Sergey, @mont29, @iss

Just quoting my comment from #71723 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...])

In #71723#814151, @lichtwerk wrote:
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)
P1166: #71723 minimal



diff --git a/source/blender/editors/space_sequencer/sequencer_edit.c b/source/blender/editors/space_sequencer/sequencer_edit.c
index 57a0d63c35e..6f0cb005eb7 100644
--- a/source/blender/editors/space_sequencer/sequencer_edit.c
+++ b/source/blender/editors/space_sequencer/sequencer_edit.c
@@ -3367,8 +3367,9 @@ static int sequencer_copy_exec(bContext *C, wmOperator *op)
     return OPERATOR_CANCELLED;
   }
 
+  int dupe_flag = SEQ_DUPE_UNIQUE_NAME | SEQ_DUPE_ANIM;
   BKE_sequence_base_dupli_recursive(
-      scene, scene, &nseqbase, ed->seqbasep, SEQ_DUPE_UNIQUE_NAME, LIB_ID_CREATE_NO_USER_REFCOUNT);
+      scene, scene, &nseqbase, ed->seqbasep, dupe_flag, LIB_ID_CREATE_NO_USER_REFCOUNT);
 
   /* To make sure the copied strips have unique names between each other add
    * 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, @mont29, @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...

Just quoting my comment from #71723 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...]) > In #71723#814151, @lichtwerk wrote: > 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) > [P1166: #71723 minimal](https://archive.blender.org/developer/P1166.txt) ``` diff --git a/source/blender/editors/space_sequencer/sequencer_edit.c b/source/blender/editors/space_sequencer/sequencer_edit.c index 57a0d63c35e..6f0cb005eb7 100644 --- a/source/blender/editors/space_sequencer/sequencer_edit.c +++ b/source/blender/editors/space_sequencer/sequencer_edit.c @@ -3367,8 +3367,9 @@ static int sequencer_copy_exec(bContext *C, wmOperator *op) return OPERATOR_CANCELLED; } + int dupe_flag = SEQ_DUPE_UNIQUE_NAME | SEQ_DUPE_ANIM; BKE_sequence_base_dupli_recursive( - scene, scene, &nseqbase, ed->seqbasep, SEQ_DUPE_UNIQUE_NAME, LIB_ID_CREATE_NO_USER_REFCOUNT); + scene, scene, &nseqbase, ed->seqbasep, dupe_flag, LIB_ID_CREATE_NO_USER_REFCOUNT); /* To make sure the copied strips have unique names between each other add * 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, @mont29, @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](https://archive.blender.org/developer/D6120)...

Added subscriber: @zargul

Added subscriber: @dr.sybren

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

In #36263#841578, @dr.sybren wrote:
@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).

@zargul I have no idea how that relates to this task.

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

In #36263#842799, @dr.sybren wrote:
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!

In #36263#187693, @slinkeepie wrote:
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!

@Domarius-1 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.

In #36263#842794, @dr.sybren wrote:
@zargul 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! :||

@iss Be sure to pursue peace. :)

Added subscriber: @crantisz

Added subscribers: @klopes-4, @ideasman42

This issue was referenced by eaee2b4119

Changed status from 'Confirmed' to: 'Resolved'

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Pasted strip doesnt have F-Curve keyframes from the original #36263