Page MenuHome

VSE operators rework
Open, NormalPublic

Description

This task should coordinate efforts for rewriting operators to python.

Motivation

  • With VSE module being rather niche use-case for Blender, it also gets very little attention from contributors. Those willing to contribue in area of operators now can contribute python code.
  • Python code is easier to maintain.
  • Python operatos will validate and test API. I believe, that all operators should use API only, regardless of language.

Personally I would like to have all VSE specific operators in one place, with preference for python, but I am not taking hard stance here.

I am aware, that operators written in python will be slower than pure C implementation. However new operator can massively reduce time required for editing.
We should find practical limit of each operator and consider if this limit is acceptable. However I think that benefits will cover potential performance losses multiple times.

Rewrite possible

If your contribution is wrapping function of another operator(s), it is better to rewrite all operators, that would normally be called in sequence.
Example: operator that is doing cut, deleting strips and removing gap in one action.

  • mute
  • lock
  • slip
  • snap
  • swap
  • strip_jump
  • offset_clear
  • gap_remove
  • change_effect_input
  • export_subtitles
  • rendersize
  • cut - This one has quite complex implementation. I reserve to work on this.
  • gap_insert - this could be tool / modal for now to allow to choose width of gap
  • reassign_inputs - must check for recursion
  • change_path - may require API changes
  • swap_data - may require API changes
  • select_grouped - I would rethink this one a bit to be a search based on selected properties, independent of current selection.

New

Before contribution, adding item should be consulted. https://blender.chat/channel/vse is prefferable channel to do this.

Remove / review

  • unmute - should be mode of mute
  • unlock - should be mode of lock
  • SequencerDeinterlaceSelectedMovies - remove, too specific to validate operator handling of checkbox
  • swap_inputs - duplicates function of change_effect_input

Implemented API

These operators are technically duplicating API functions.
Before rewriting these I have to look at current implementation and consult if they should be rewritten.

  • delete_strip
  • scene_strip_add
  • movieclip_strip_add
  • mask_strip_add
  • movie_strip_add
  • sound_strip_add
  • image_strip_add
  • effect_strip_add
  • strip_modifier_add
  • strip_modifier_remove

Add to API

  • Sequence.duplicate
  • ImageSequence.images_separate
  • SequenceModifiers.move
  • SequenceModifiers.duplicate

Conventions

  • If operator can not run, or finish action, report a message explaining why (in human language)
  • No hacks. If there is some issue, that is not clear how to resolve, let me know
  • Use https://docs.blender.org/api/blender2.8/bpy.ops.sequencer.html as a reference of current operator options / modes
  • Avoid calling other operators from within operator.

Details

Type
To Do

Event Timeline

Proposals like this should explain the motivation (pros & cons).
What advantage does this have to rewrite these in another language?

There is an obvious benefit in one case, eg: export_subtitles makes sense to be in Python since text handling & string manipulation in general is more flexible in Python.

I'm not sure what there is to gain in other cases though.

  • Interactive operations especially seem like they would be worse off if rewritten in Python, (slip for eg), since Python can have noticable overhead.
  • Operators that just toggle a setting doesn't seem like much of a difference either way. mute/unmute, hide etc.
  • Moving images_separate to an API call then adding the operator from Python seems like a token. All the Python operator will do is call the C API code which will have all the logic. How is this an improvement?

The idea was to make it possible for Python developers to contribute to the VSE more easily and maintain these operators. The operators being object-like, they're easier to write, read, and encapsulate in Python: in C you need several functions.

We're a few who'd like to add missing features or improve some existing operators and it'd be easier to prototype, iterate, and maintain Python code in general compared to C. We'd have many operators written in the same way, language, and place.

Writing this, and thinking about it again, I guess that unless we want to improve an existing operator or change the way it works, as many of these are basic building blocks of the VSE, they don't need to change often, so there might be few practical benefits.

Richard asked for some new operators or features we'd like to suggest as part of this project. I wrote and played quite a bit with the VSE with our add-on power sequencer. I've written operators that help to edit all kinds of content faster than with vanilla blender:

  • A modal, mouse-based tool to trim individual sequences, insert cuts (like the standard razor tool in many NLEs) or time ranges. It reduces keystrokes a lot compared to Blender's workflow. Also, the VSE in 2.80 does have some mouse-based interactions, but no interactive tools to edit with the mouse yet. The goal with this versatile operator would be to help fill this gap.

  • Concatenate strips: removes the gap in a single channel with the next strip, previous strip, or entire channels. There again it helps to reduce keystrokes, offers more flexibility compared to vanilla blender. I use it almost daily for all sorts of edits where the strips aren't linked in time, which has been common in the work I do: overlaying images on the edit, cutting audio, etc.

There's more we've been discussing around the VSE chat and would like to contribute using Python. I'd personally like to help with tools in general.

Although these two proposals would need discussion and approval in separate tasks, what I got from the discussion with Richard is that the point of this task is to discuss and get approval to have more Python code for VSE operators, to make it a lot easier for add-on and Python devs like me to contribute.

Are new tools or ops written in Python welcome in the Sequencer project?

  • Moving images_separate to an API call then adding the operator from Python seems like a token. All the Python operator will do is call the C API code which will have all the logic. How is this an improvement?

Operator will not return reference to created strips. It can do this only indirectly by selecting them, them.
By doing this user has to save selection state, do stuff, and restore selection. Not a good practice IMO.

  • Moving images_separate to an API call then adding the operator from Python seems like a token. All the Python operator will do is call the C API code which will have all the logic. How is this an improvement?

Operator will not return reference to created strips. It can do this only indirectly by selecting them, them.
By doing this user has to save selection state, do stuff, and restore selection. Not a good practice IMO.

Improving the Python API is fine, this doesn't have to be tied to moving operators to Python though.

We could just make sure the Python API is *complete*,
that C/Python-API calls share the same code.
(this is mostly what's been done elsewhere in the Python API, managing key-frames is an example of this).

So actions you would want to do from Python don't require calling operators which can be awkward.

Although these two proposals would need discussion and approval in separate tasks, what I got from the discussion with Richard is that the point of this task is to discuss and get approval to have more Python code for VSE operators, to make it a lot easier for add-on and Python devs like me to contribute.
Are new tools or ops written in Python welcome in the Sequencer project?

I'd assume so, but check with @Richard Antalik (ISS).
I'm surprised there is interest to rewrite operators in Python.

Unless changes to these operators are planned (which benefit from being written in Python), wouldn't it be better to focus on improvements to the API and designing/writing new tools?

user has to save selection state, do stuff, and restore selection. Not a good practice IMO.

True. The VSE's Python API has us mutating the strips and the context directly, moving the time cursor around inside an operator and moving it back at the end of the operation.

wouldn't it be better to focus on improvements to the API and designing/writing new tools?

Makes sense. I'll let Richard share his thoughts.

I'm surprised there is interest to rewrite operators in Python.

In earlier attempt there was some criticism, that for example we are trying to implement multiple cut operators, that each do something just a bit different.

I agree with this point, and I am expecting the same thing to happen as last time - attempt to implement operators that do either work of more operators, or does something in a different way.

I will have no problem with adding only new operators. However I would definitely want to rewrite cut. I can do that in C, but I don't want to spend week doing that. it's current code is impressively bad.

In any case, this task is what I consider to be the best strategy, with consideration for past discussions and interests of all participants.

I am trying to be quite conservative in development, because I am aware, that there is a lot of things, that I don't know. Even then, I would say let me burn if this goes wrong. That's how I learn.
But I am listening to any suggestions, criticism or restrictions.

For example in case of select_grouped I didn't realize that this is quite strong Blender convention, So I will be remove it from this list. These lists are rather informal anyway - I assessed each item just by reading its code and documentation description.

With this task proceeding to be one of main goals for 2.81 My plan is to focus on usability issues in VSE, as they are closely related. This task wasn't my preference for next release, but there is great interest from contributors.

I guess It's all I had on my mind for now.
Sorry for rant, somehow I feel, that I am being misunderstood in my general stance here.

Are new tools or ops written in Python welcome in the Sequencer project?

Of course!

I think that preferably you should start creating new stuff, and realize in process that "if only I could tweak this exiting operator..." :)

Perhaps you missed, but I announced in chat VSE channel, that ideas for new operators and functions are welcome and if you can give me some list that would fit possibly most users, I will put it here and we can look at all new functions,assign them piority and do some guesswork of how much time and resources will be required.

I think that preferably you should start creating new stuff, and realize in process that "if only I could tweak this exiting operator..." :)

In our respective add-ons, Snu and I rewrote remove gaps, he rewrote grab, etc. For instance, I had to remake functions so that locked strips are really locked and not affected by every operator.

Also, definitely, I wrote dozens of python operators. I'll prepare a list of a few features I think could benefit everyone's workflow.

Can you add operators for in and out marking and editing? essential for workflows that use a device with a wheel for scrubbing, marking and editing. the reliance on the mouse for operations is a limiting factor when trying to map shortcuts to midi events etc. ideally use named markers if possible.