When checking functionality, I got crash after transformation if no keyframes were present - null dereference of fcu. Don't see fcurve created anywhere in this patch too.

In T98015#1365188, @Philipp Oeser (lichtwerk) wrote:

I think it makes sense to split this report up in multiple reports (will do that).

In T98015#1364993, @Richard Antalik (ISS) wrote:

Ah right that's correct. Not sure what would be good solution. Sounds to me that in case when property is animated, cache entry should be created only when keyframe is inserted, but even that is not quite enough - it would have to check if all properties that were changed were keyed. Looks quite complicated to handle this.

Havent looked at cache internals (where the entries are made, when/how exactly this get invalidated), could check if you give me a hint, but looks like this is essential funtionality that is just behaving wrong (by design?)

The dependency graph is following the design within which there is a separation between data and its state. Basically, data is the .blend file and state is the result of the dependency graph evaluation. This enforces all areas adjacent to the dependency graph and scene evaluation to support such separation. This is something what might not be fully done yet due to various reasons.

Testbuilds up https://builder.blender.org/download/patch/

CCing @Campbell Barton (campbellbarton) only for the case of ED_autokeyframe_property being called from a gizmo

I have split this up in multiple reports (claimed the first three related to autokeying for now), see
T98429: VSE autokeying transforms in preview only creates keyframes for rotation/scale if rotating/scaling around cursor (should keyframe position as well)
T98430: VSE autokeying transforms in preview only creates keyframes if there is an FCurve already
T98431: VSE autokeying transforms in preview does not work during animation playback
T98432: VSE unkeyed transforms in preview persist in cache
T98433: VSE keyframed transforms in preview persist in cache after keyframes have been cleared

CC @Richard Antalik (ISS)
CC @Omar Emara (OmarSquircleArt)

CC @Richard Antalik (ISS)
CC @Omar Emara (OmarSquircleArt)

CC @Richard Antalik (ISS)
CC @Omar Emara (OmarSquircleArt)

CC @Richard Antalik (ISS)
CC @Omar Emara (OmarSquircleArt)

CC @Richard Antalik (ISS)
CC @Omar Emara (OmarSquircleArt)

@Richard Antalik (ISS): you also have not commented on the "persting-after-clearing-animation" issue (if this is a duplicate of the mentioned report)

I think it makes sense to split this report up in multiple reports (will do that).

But I can reproduce difference in color strip animation when scene strip is enabled/disabled, so I guess this would be enough to investigate.

@forceengine Yes I can check on Linux, but not really debug at least easily. But since you report different OS to be working correctly which implies different settings, can you check if you have disk cache enabled on Linux installation and if issue will happen when you disable it?

Ah right that's correct. Not sure what would be good solution. Sounds to me that in case when property is animated, cache entry should be created only when keyframe is inserted, but even that is not quite enough - it would have to check if all properties that were changed were keyed. Looks quite complicated to handle this.

In T98287#1363806, @Richard Antalik (ISS) wrote:

I don't understand how can I see the issue from provided still frame in comment above - what frame number is that? Looks like frame 61, which is what I see in preview. Is that incorrect?

If I can reproduce on windows, it would help a lot, because I don't have linux machine with dev environment set up.

In T98015#1364664, @Richard Antalik (ISS) wrote:

In T98015#1364264, @Philipp Oeser (lichtwerk) wrote:

However, I am not sure how to prevent the "hop" when transforming (but not actually setting a keyframe)

If I understand this correctly, the "hop" frame from report was the only correct frame, since it was rendered after transformation was done. So I would say if keyframes would be set this would not happen.

Yes, if you would set a key there, this would be fine.
But if you dont set a key there [which is totally fine], this is wrong. And this has nothing to do with autokey or the cursor rotation (see my previous example/comment).
Once you change frames, the unkeyed change needs to vanish (but atm. it remains in the cache).

In T98015#1364264, @Philipp Oeser (lichtwerk) wrote:

However, I am not sure how to prevent the "hop" when transforming (but not actually setting a keyframe)

In Blender 2.x I could export any video resolution I wanted and it did the business, now in 3.x a project seems to be stuck at whatever resolution it was started in. Is there a work around for this?

I just investigated a bit and it seems like this bug was introduced by @Sergey Sharybin (sergey) in rB89946834a17 with an improper fix for the issue of a Camera strip playing audio. I assume he never tested setting it back to Sequence afterwards. @Sergey Sharybin (sergey) can you fix this please?

Well, theoretically you only have to call BKE_sound_add_scene_sound[_defaults] when the sound of a scene should be played and call BKE_sound_remove_scene_sound when you want to remove that sound again using the handle you got as return value from the first call. So all you should have to do is to make sure that for a scene strip with input Camera this is not called at all or removed if it is changed and vice versa for the input Sequencer.

@Richard Antalik (ISS): I have most of the autokeyframing improvements done (will clean up the patch and post tomorrow)

No activity for more than a week. As per the tracker policy we assume the issue is gone and can be closed.

Also noticed this should probably respect autokeying setting which relate to Keyingsets (will also check on that) as well as Replace / Add & Replace -- not sure about Layered Recording (but is worth checking also.

Also noticed that autokeying image transforms in preview only works if you have a keyframe already (this is inconsistent with auto keyframing elsewhere, will also check on that)

@Richard Antalik (ISS): what about the persistence thing then? should we split that off of this report?

I can reproduce the issue. What seems to be happening is that the red color strips have animations that sometimes gets evaluated at the active scene frame and sometimes gets evaluated at the frame of the scene of the scene strip of the clock.
While they should always be evaluated at the frame of the active scene as far as I can tell.

Seems to happen with many files, but here is this particular one.

Can you provide video file? I can't reproduce still. Could be ffmpeg issue as well.

Ah sorry I did rotation around strip pivot point, not 2D cursor. So I can reproduce and indeed I think that position should be keyframed in this case.

I am checking on Windows, so this could be the reason for me not being able to reproduce. From videos in description it looked to me that issue is flickering of animated color strip. I don't understand how can I see the issue from provided still frame in comment above - what frame number is that? Looks like frame 61, which is what I see in preview. Is that incorrect?

In T69444#1363761, @Joerg Mueller (nexyon) wrote:

In T69444#1363251, @Richard Antalik (ISS) wrote:

There are developers that seem to be able to implemet features in audaspace though so hopefully.

How is this an issue in audaspace? For me it sounds this issue has to do with the blender side of things? I wonder if this is one of the issues introduced with the depsgraph?

In T69444#1363251, @Richard Antalik (ISS) wrote:

There are developers that seem to be able to implemet features in audaspace though so hopefully.

In T98287#1362823, @Omar Emara (OmarSquircleArt) wrote:

It seems the file does not include the images necessary to make the clock, so I can't exactly replicate the sequence. Can you pack into the file or attach the necessary images?

I can confirm (both the persistence after clearing the animation as well as the "hop").

In T69444#1363251, @Richard Antalik (ISS) wrote:

In T69444#1362516, @gilad (giladf11) wrote:

Hi, is this bug going to be fixed anytime soon? is there any workaround for the meantime?

Anytime soon I can't tell. I am not sure if there exists infrastructure to handle this issue. There are developers that seem to be able to implemet features in audaspace though so hopefully. For workaround, I would think that duplicating scene and using one solely for sound and another for image would work?

Adjusting any property invalidates the cache and also fixes the issue.

• Update after first review

Reopening the file fixes the issue, so it seems to be a cache issue indeed.

Disk cache is not enabled.

@Peter Fog (tintwotin) is correct that if you change scene frame range, this is not reflected in scene strip(reverse of what is done in this patch) I have found D2322 that tried to fix this. In different patch I remember concern, that if sequencer using particular scene is in different .blend file, such automatic update would not work.