Ok so I tested this, seems good, but:

• Clear fades operator isn't available from UI, unless it is searched. It really should be.
• How can I choose duration as shown in demo? I mean functionality is provided by from/to playhead, but just asking if this was dropped or something.

Done with the changes. Only one left: the duration_seconds thing. Should I remove it and have the operator work in frames instead, to be consistent with the rest of Blender?

• Sequencer: add SequencerFadesClear and SequencerFadeAdd operators
• Add FadesAdd operator to the Add menu
• Capitalize names for menu entries
• Fix edge case when clearing keyframes
• Ensure the fade is at least 1 frame long
• Fix poll methods, turn fade functions into methods

Regarding complexity: that's what it takes to provide the functionality. There are parts of the API that are a bit inconvenient, e.g. sequences don't have animation data attached to them, so you need code to find and create anim data on the scene's anim action, etc. Same, there's no notion of fades in the VSE's back-end, so you have to code everything. 200 isn't a lot if you keep this in mind + the op's features. The high-level process is pretty clear as well, it should be easy to maintain:

@Peter Fog (tintwotin) I feel you...

I confirm problem ubuntu 18.04 64bits NVIDIA Titan Black.

Without these Annotation Tools exposed, the Annotations aren't of much use in 2.80. Why not expose them for now, and make it at least usable, until a proper toolbar is implemented?

We should not add those buttons. They are insanely clumsy to use, because you can only draw one stroke at a time.

It is possible to add the Annotation Tools to the Sequencer Sidebar, but the functions do not seem to work:

@Richard Antalik (ISS)

Don't really like the complexity of this OP, but that isn't any dealbreaker, as this is covering functionality, that should be native, thus temporary.

@Richard Antalik (ISS): yep, see D5300

In T66682#727252, @Vincent Girès (VincentG) wrote:

By curiosity, I tried to use the config.ocio file from 2.80 in 2.79 and there is no issue while using the config file of 2.79 in 2.80 still have not identical render with the two files I've uploaded. It's then probably not related to the new ocio file and something has been broken in 2.80.
Hope it helps.

By curiosity, I tried to use the config.ocio file from 2.80 in 2.79 and there is no issue while using the config file of 2.79 in 2.80 still have not identical render with the two files I've uploaded. It's then probably not related to the new ocio file and something has been broken in 2.80.
Hope it helps.

In T67181#726605, @Philipp Oeser (lichtwerk) wrote:

@Richard Antalik (ISS) : you added this, mind checking?

Placing my bet for missing depsgraph update.

Confirmed, checking...

@Richard Antalik (ISS) : you added this, mind checking?

@Richard Antalik (ISS) A related problem occurs, when an EffectStrip is annimated and Shift+S is used, with only the “_Testfile_01.001” selected.

The exposure/gamma setting make noise only when audio scrubbing is checked.

In T66682#723172, @dark999 (dark999) wrote:

@Vincent Girès (VincentG) your GPU is not officially supported from Blender, it is too old to match minimum Blender requirement
https://www.blender.org/download/requirements/

Indeed, I was reporting the bug on my laptop. Here is my working machine where it does the same for both issues:
Operating system: Linux-3.10.0-327.el7.x86_64-x86_64-with-centos-7.2.1511-Core 64 Bits
Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 390.77

In T66891#723558, @KiJeon (0o00o0oo) wrote:

If nothing else, if it would result in the expected behavior of live updates like in 2.79, then I think not using cache by default makes sense.
Is that how it worked in 2.79?

If nothing else, if it would result in the expected behavior of live updates like in 2.79, then I think not using cache by default makes sense.

@Vincent Girès (VincentG) your GPU is not officially supported from Blender, it is too old to match minimum Blender requirement

Not sure if this is valid request. AFAIK this is near to impossible to implement.

d62a749fcf48 is not that old, though I am not aware of any changes here.

@Richard Antalik (ISS) can you look into this?

Master is frozen.
only critical bugfixes are allowed

So is the UI change with 'End' going to be rolled back for now?

In T66682#718002, @Richard Antalik (ISS) wrote:

see T65271: Using Filmic view transform causes VSE to be lower contrast than it should be

This is a different topic. I'm not talking about display result with Filmic which dipslay of course sRGB files less contrasted but this normal.

We require a .blend file and exact steps to reproduce the problem.

With a movie strip displayed on the sequencer, changing the sequencer_colorspace_settings property in the Color Management changes the look of the image even when there is no color correction modifier on the strip. Example: using filmic log instead or sRGB will change the look which it should not.

see T65271: Using Filmic view transform causes VSE to be lower contrast than it should be

You're right, (was looking at the edit strip panel which only has start frame & length).

The offset(hard/soft cut) values have been exposed as buttons in many years(without limits on invalid values). Here they are in Blender 2.72:

These were internal variables for cutting strips and not meant to be exposed.

According to this comment it is a way to workaround that bug:

In T65723#717723, @Peter Fog (tintwotin) wrote:

I don't know if changing the 'End' value to a label is a fix for the above mentioned bug?

I don't know if changing the 'End' value to a label is a fix for the above mentioned bug?