VSE operators rework #65724
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#65724
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This task should coordinate efforts for rewriting operators to python.
Motivation
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
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
Conventions
Added subscriber: @iss
Added subscriber: @ideasman42
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.
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?Added subscriber: @GDQuest
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:
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?
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.
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?
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.
Makes sense. I'll let Richard share his thoughts.
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.
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 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.
Added subscriber: @Enetheru
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.