Page MenuHome

Sequencer: restructuring the code layout
Confirmed, NormalPublicTO DO

Authored By
Richard Antalik (ISS)
Jun 7 2020, 8:59 PM
"Love" token, awarded by VincentG."Love" token, awarded by Xlindvain."Love" token, awarded by bnzs."Love" token, awarded by AndyCuccaro."Like" token, awarded by duarteframos."Love" token, awarded by Pipeliner."Love" token, awarded by pablovazquez."Like" token, awarded by pistolario."Love" token, awarded by jorsh."Love" token, awarded by vitos1k."Love" token, awarded by Andrea_Monzini."Love" token, awarded by Draise."Burninate" token, awarded by Gorro_Rojo."Love" token, awarded by Christopher_Anderssarian.


Note: This is initial proposal aimed to gather feedback. It is subject to change.

This is task to coordinate restructurization of majority of VSE code.
Goal is to break existing code to smaller files with relatively narrow scope, create layer isolating low-level BKE code from functions close to user (operators, RNA, drawing). There should be minimum functional changes in first stages, followed by cleanups with minor functional changes if necessary (logic consolidation).


  • Maintainability in general
  • To allow work on T59540, where it is important for drawing, RNA and operator code to follow exact same logic to produce correct results.
  • Make it easier and cleaner to make changes in rendering code

Since this will be relatively large operation, it will have to be done in few stages:

Event Timeline

Generally is super nice to have sequencer better organized from the code point of view, and de-duplicate logic as much as possible.

As for the locations of the files I don't think they belong to editors. Editor API should not be used by render pipeline, for example. To me it seems that sequencer should become more top-level folder, like compositor is, and used by render pipeline, sequencer space and so on.

As for the approach of how to structure the changes:

  • Try to move files as-is to the neighbourhood of their destination
  • Split them up at their final destination

Moving files can happen as a bulk operation, since that'd be annoying to keep incrementally modify entire source code. Splitting up and other changes try to keep as isolated as possible, in a stream of commits.

For the planing, it seems like this is an involved change, and we have quite reasonable amount of reports which doesn't seem to be requiring such refactor. To me it seems for 2.90 is better to do stabilization pass, and aim this refactor for 2.91. Hence i'll place this to 2.91 column. Surely, some work can start early on, but finalized (with all the cleanup and de-duplication you've mentioned) is unlikely to happen for 2.90 due to time constraints.

This is my vision anyway. Since there is some source layout/etc involved, wouldn't mind if @Brecht Van Lommel (brecht) shares his strong opinion :)

Thanks for input, I agree with all points here, so I will change description with more discrete steps that can be checked out. Will have to look at compositor code organization, but I suspect that I will probably want to keep alloc/free functions in BKE if I wanted to make strip a ID at some point.

Dalai Felinto (dfelinto) changed the task status from Needs Triage to Confirmed.Jun 24 2020, 5:14 PM

Just curious, as I see a lot of files being moved around now for this project, but has the advantages of moving the Sequencer data out of Scene data, so Scenes can be switched without switching Sequencer contents, and vice versa, been taken into consideration?

Some of the benefits:

  • Having the sequencer scene strip preview in the 3d view((no switching)good for storyboarding, previz etc.
  • A source and a master edit preview in the same workspace(as the VSE 2.0 mock-up, but both previews are Sequencer previews(just different Sequences))
  • Pancake editing workspace(all footage in one sequence and all edited material in another) in the same workspace.
  • Accessing sequencer-data-block from everywhere like node editor, 3d view background(ex. grease pencil drawing on edited sequence) and texture material, which can be manipulated in node editor and returned to VSE as scene strip.

More on the advantages here on RCS:

I fully support Peter's proposal of moving the sequencer out of the scene. I've been thinking a lot lately about how the sequencer fits into the Blender file/scene hierarchy (and I'll make a mockup of some ideas I have on this and on the compositor as soon as I can).

In the end, the sequence should be the final step of the production, no? Thus, I think it's more logical to have the sequence be the "parent" of the many scenes within the blend file than the other way around. And, like Peter mentions in his proposal, it could open the gates for a more streamlined workflow for storyboarding, for example.

Please, please consider doing this change.

This task is purely about restructuring the code layout, please move discussion about changes to functionality elsewhere.

Brecht Van Lommel (brecht) renamed this task from Gigantic VSE refactor to Sequencer: restructing the code layout.Sep 10 2020, 5:45 PM
Brecht Van Lommel (brecht) renamed this task from Sequencer: restructing the code layout to Sequencer: restructuring the code layout.

This task is purely about restructuring the code layout, please move discussion about changes to functionality elsewhere.

It has been at RCS since aug. 2018, but no devs there to discuss it:

As of rB18d7aeacf2f7: Move sequencer sources from blenkernel there is:

./source/blender/sequencer/BKE_sequencer.h (outside of ./source/blender/blenkernel).

I think we shouldn't leave partially finished module re-arrangement in this state.

While multiple commits to move and rename can be OK, it's leaving a mess to keep a module split-up and spread across different directories - longer term.

I will clean up that file on one or two commits (split + rename).

There will be still bunch fo functions with BKE prefix, so unless this is done in one go, there will have to be undesirable state for some time.

I will try to resolve this state in first place and as quickly as I can. I already got one file split, but perhaps it would be better to start with BKE_sequencer.h actually - it would make subsequent splits even easier.