rename parameter

In D14819#406142, @Colin Basnett (cmbasnett) wrote:

A bit. I did a survey of all that functions I could find that modify the markers or the markers list in a way that would require the list to re-sorted: [ snip 13 functions ]

But this still does not address other issues such as need to change strip range, but mainly dealing with read only scenes. Testing bit more, cache has to be invalidated as well.

How much work would it be to ensure that markers are always stored in frame order?

Timeline marker names are now correctly clipped instead of messily overlapping each other and being unreadable.

Text size is not adjusted to fit when there is a resolution change and Preview is not updated either:

Just pasting the previous relevant quotes from T98015:

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

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

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

Sorry, yes, that would be same issue as described in T90041.

fix flipped condition for assert (Debug builds)

In D15047#405617, @Richard Antalik (ISS) wrote:

When checking functionality, I got crash after transformation if no keyframes were present - null dereference of fcu.

Cannot repro, are you testing a Debug build?

@Richard Antalik (ISS) When the scene is deleted of a scene strip, the strip gets a red line. This should happen to all strip types when the source is gone missing, and currently it doesn't.

Since all files are loaded on demand, on only thing that could be done is to produce warning after rendering. I could create state check to communicate such event to render job, perhaps it would be simple to report warning per file or strip.

Could be some inaccuracy in code, because with wrap values different than 0.75 it matches.

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/D15047/

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 having two strips, one with Camera and one with Sequence. @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.

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

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

I often see errors mentioned above, but these do not affect image output.

I agree that this was not great change, so will consider this as a bug.

I just wanted to mention, that I will accept whatever solution you and @Joerg Mueller (nexyon) will agree on, and sequencer stuff looks mostly reasonable. Only thing that stands out a bit for me is soundeqs field of Sequence. It's not really bad to have this separated from image modifiers, but if there should be more sound modifiers, I think, that these should be wrapped in more generic struct(similar to image modifiers), but this is probably detail compared to actual sound stuff.

This doesn't quite look like one of issues above, cache should be cleared since strip property was changed. I can't reproduce this issue with steps provided.

In T98168#1360793, @Pratik Borhade (PratikPB2123) wrote:

Yes, can confirm with meta strips.
I found a few reports which are probably related to this-
T71723: VSE (2.81): Copy-pasted meta strips lose all key frames
T68160: Keyframes lost when copy-pasting strips
I'm not sure if behavior is same since these reports (haven't tested myself on older builds).
@Richard Antalik (ISS), Is this a known issue?

@Omar Emara (OmarSquircleArt) @Melan Meilsheim (Deckelmouk) I can't reproduce this issue, can you provide .blend file where this happens?

@Evan Wilson (EAW) Seems very similar indeed, I will merge. Thanks!

This report reminds me of T60947: FFMpeg color offset. Possible duplicate?

I can replicate the difference in MPV even with lossless output. But I am not sure if this difference is expected, so tagging the module for more information.

If I hold split a sequence at frame 22, the start of the second strip will have frame 18 as its first frame, then it continues normally starting from 22.

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?

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

This looks better already.

Was this fixed? I don't want to deal with update just to find out its still not working, thanks!

• Show option only for Strip Scene type

Improving the connection between the source scene time edits and the scene strip time edits is a good idea, IMO. The culprit is that the source scene range isn't linked to the hold values, The hold values and the scene strip source scene range values are displayed in the Time panel, when a Scene strip is an active strip:

i noticed also that if we set rotation 600° as preset then rotate using shortcut 'R' 'without any change'we can notice that the value will go to between 0° and 360°.
so there is a modulo by 360° which it will miss with any animation that was done .....
SO i propose to make addition instead of modulo '-360......360'

I can confirm.
Although the header and transform values are inverted, maybe they could match a little better.

Thanks for the report, but it's not a leak. It's just the caching system.