VSE operators rework #65724

New Issue

Richard Antalik · 2019-06-11T15:29:35+02:00

Richard Antalik commented

2019-06-11 15:29:35 +02:00

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.

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.

Richard Antalik commented

2019-06-11 15:29:35 +02:00

Added subscriber: @iss

Campbell Barton commented

2019-06-12 07:53:29 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2019-06-12 07:53:29 +02:00

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?

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?

Nathan Lovato commented

2019-06-12 16:22:39 +02:00

Added subscriber: @GDQuest

Nathan Lovato commented

2019-06-12 16:22:39 +02:00

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.

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.

Nathan Lovato commented

2019-06-12 16:44:13 +02:00

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?

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. ![68747470733a2f2f692e696d6775722e636f6d2f775676583465782e676966.gif](https://archive.blender.org/developer/F7100327/68747470733a2f2f692e696d6775722e636f6d2f775676583465782e676966.gif) - 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. ![68747470733a2f2f692e696d6775722e636f6d2f5979454c3859502e676966.gif](https://archive.blender.org/developer/F7100323/68747470733a2f2f692e696d6775722e636f6d2f5979454c3859502e676966.gif) 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?

Richard Antalik commented

2019-06-12 19:45:21 +02:00

In #65724#699723, @ideasman42 wrote:

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.

> In #65724#699723, @ideasman42 wrote: > - 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.

Campbell Barton commented

2019-06-13 00:09:58 +02:00

In #65724#700165, @iss wrote:

In #65724#699723, @ideasman42 wrote:

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.

> In #65724#700165, @iss wrote: >> In #65724#699723, @ideasman42 wrote: >> - 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.

Campbell Barton commented

2019-06-13 00:25:40 +02:00

In #65724#700094, @GDQuest wrote:
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 @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?

> In #65724#700094, @GDQuest wrote: > 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 @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?

Nathan Lovato commented

2019-06-13 02:26:14 +02:00

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.

> 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.

Richard Antalik commented

2019-06-21 07:51:29 +02:00

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.

> 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.

Richard Antalik commented

2019-06-21 08:01:29 +02:00

In #65724#700094, @GDQuest wrote:
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.

> In #65724#700094, @GDQuest wrote: > 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.

Nathan Lovato commented

2019-06-22 01:32:04 +02:00

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.

> 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.

Samuel Nicholas commented

2019-06-22 05:18:25 +02:00

Added subscriber: @Enetheru

Samuel Nicholas commented

2019-06-22 05:18:25 +02:00

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.

Richard Antalik added this to the Video Sequencer project 2023-02-09 20:57:27 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

VSE operators rework #65724

Motivation

Rewrite possible

New

Remove / review

Implemented API

Add to API

Conventions