I can't replicate the crash myself. But the videos does not play correctly and seems to have uninitialized memory and other issues. So a crash seems plausible and this should probably be looked into by a developer.

Thank you for working on this. Some feedback on the current design:

Than you!!!

First of all, having good controls over audio is indeed something needed for the VSE.

I talked to @Sergey Sharybin (sergey) that day who seemed to have some concerns about this patch (which i mistakenly assumed he would make clear) and did not move forward until I'm getting some indication this may actually land in the near future

Still freezes in current 3.2.2 RC build 9d38a2d21c97
Works in 3.1.2 and before.
I did some more testing and found that it seemingly only affects packed .wav and .flac files. If those files are linked instead of packed, the freeze does not occur.
Other file formats seem fine even when packed.

Fixed an out-of-date comment.

Fixed compiler warnings.

Seems it is agreed that this should be archive. Feel free to reopen otherwise.

Seems to be the same as T99817 and T99812, though slightly different.

In a DM on Blender Chat you voiced your concern about the const int ELEVATED = 0x10; flag. I share that concern, and I think that it would indeed be good to gather such marker flags in one spot. I also agree that that's for another patch ;-)

Seems to be the same as T99817, though slightly different.

A thread seems to be fully occupied here indefinitely.

Addressed feedback

• Removed additional markers_elevated list in favor of using marker flags
• Updated comments to match style and add clarification

Yes, maybe the name Current Frame is not the best. IMHO we could archive this bug and if we discover any problem we can open a new one.

I was able to reproduce now, but I had to do a few attempts. So no need for recording.

Yes, can repro it every time. I'll attach a screen recording (maybe that will help)

Current Frame is purely informative value which is calculated from strip and current frame position. This has nothing to do with content start - if you move strip handle it still counts from 0.

It's not a bug, because in VSE strips are visualized by area, in timeline editor you mostly look at points (keyframes). This means that strip starting on frame 250 must end at least on frame 251. Or in other words, try to set range so that 1 frame is rendered (range from 1 to 1) - this looks correct in VSE, but not in timeline editor. With bigger frame ranges this looks off.

I was not able to reproduce - is this reproducible every time for you?

As a side note, I've seen that using Reload Strips temporarily solves the problem, but still the panel information is wrong. Also, if you edit the original scene, you get the same problem again.

Before using a daily build, I reset Blender 3.2.1 to factory settings and can no longer reproduce the issue either. It must be some strange bug owing to my personal settings. Not sure how.
Seems like an edge case that doesn't really matter. Thanks for looking into it.

I talked to @Ray Molenkamp (LazyDodo) 21 days ago. He said that he would talk to the maintainers dependencies.

I cannot reproduce this with either the latest stable or current development versions of Blender (with ASAN build):

@Ray Molenkamp (LazyDodo) Would you know something about neXyon's question above?

Thanks for the update. Have you contacted the platform maintainers yet about getting both the float and double versions of fftw as dependencies?

In 3.3 you can resize strip by moving handle, but that is by accident actually.

unfortunately my asan build terminates before I can check anything, so will have to manually configure this for specific area.

I can not reproduce, sounds like unsanitized/uninitialized memory access, will try to check with ASAN.

Don't think bisecting is necessary, will fix today.

rB7afcfe111aacc8bc3f456a3287d3cc34765b798a is the only relevant change between these broken and working builds
cc @Richard Antalik (ISS)

Thanks for patch, gradients look fine, I have left mostly nitpicks, but texture size limitation needs to be resolved.

Using linear colorspace is probably not what you would want to do in this case, but changing transformation filter to "Nearest" or enabling Convert To Float in color properties should work without affecting color (within limitation of float/byte spaces).

• Removed the broken color management.
• Switched to less distracting checkerboard colors.
• Fixed double unbinds. Now the UI code should hopefully be a bit more sane.

Transition color gradient drawing:
Note that currently this patch won't look right, because of bugs in the sequencer timeline.
I think the way the transition and meta strips are drawn could be changed to be more like other strips: background for the title, and strip contents below it. Even before this change the title was quite hard to read with some input colors. I can do that in another patch.

I couldn't find any good way to evaluate drivers at different frames, so this diff falls back to redrawing every frame, if the color strips have drivers.

Version 3.2.1 on Ubuntu 22.04 LTS
Older ATI Radeon 5890

Can confirm. Using linear color space for the image removes the dark border.

In D15363#415606, @Peter Fog (tintwotin) wrote:

Upon testing it seems the transitions unfortunately have been broken(GIF) by this patch:

The gradient color strips looks super great!

Changed the Diff in order to address comments by Nexyon and ISS
Specially:

• removed EqualizerReader. All from Equalizer to ConvolutionReader
• constants and the leadership of creation and sizes, taken in the Blender part
• buffer of communication con Audaspace created in Blender part
• With a Selector, the user can create 1, 2 or 3 graphical band definitions
• with Python API, user can delele all the graphical band definitions, and create one by one
• changes in names of structs and functions suggested by ISS
• improvements and simplifications commented by ISS
• limited modifications to +/-30 dB and cut the data from the curve mappings to +/-30 db

This might help clarify/extend the backtracking in Blender versions
But the last one I used is 3.0

Thanks Batman
.. I've always wanted to say that xD

I can confirm the crash.

I can confirm the change in behavior when dragging and dropping from system file explorer.

I've debugged the text wrapping code flow and couldn't find anything wrong with width, height, size values coming into blf_font_wrap_apply from VSE point of view. And at first glance the wrapping calculation seems consistent. I reached out @Harley Acheson (harley) to understand the root cause. So the possible reason could be:

Wrapping code uses a measure of the string that should only ever overestimate by about the space between a pair of characters (because it includes the space after the last one) so is usually within a couple pixels of perfect.

This behavior was changed in commit 7afcfe111aac. Function scene.sequence_editor.sequences.update() is not part of sequencer API, looks like it's for collection class itself. There is no update function for time data anymore as it is not needed.

I am happy with the code functionally as well, left mostly nitpicks and suggestions.

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

Caused by rB7afcfe111aac: VSE: Make time operations self-contained

looks like a regression, will check

Yes, I can confirm the inconsistency. After debugging it, I see the preview window is doing the wrap calculation based on unscaled resolution while rendering uses the line width from scaled resolution when I follow the repro steps.
So is it better to align preview to render flow and use scaled scene resolution for word wrap or the other way around?
But even if the Proxy Render Size is set to Scene Size to have same text wrap result for render and preview window, changing scaling between 50% and 100% generates different wrapping results. This's mostly because of because of having the wrapping calculation in BLF_wordwrap using scaled down integer width value. Investigating if it can be done in a better way.

Fixed in 3.2.1 candidate. Great job!

The audaspace side of the patch starts to look good, mostly there is only minor changes left I would say:

Just a note, that this is not caused by rB7d1a10a9bbf3 - it was likely issue since first implementation of thumbnail drawing. It's likely, that before this commit thumbnails were not drawn unless you zoom in timeline a bit.

Raising the priority since it's a regression (can't repro in 3.1)

Well, having it fail without any useful explanation, will be perceived as a bug by most users and it doesn't go well with the declared ambition of the VSE "should just work".

At the moment this information above is available if you turn on ffmpeg traces by launching blender with --debug-ffmpeg argument. So I'd say exposing it in a more user friendly way or making the ffmpeg integration project settings aware is an improvement rather than a bugfix.

Caused by rB7d1a10a9bbf3: Fix T93314: Thumbnails not drawn with default scale

Crash seems to be hapenning in swscale, so this is not a bug in Blender.

Seems to be stuck here.