Wed, Jun 19
Mon, Jun 17
@Richard Antalik (ISS) - If you have a moment while going through the VSE functions when updating the manual, could you check the values in the "Timecode" Panel, if they make sense to you? For me, several of them do not. Here are my notes:
- Is it correct 'frame_start' should show the mouse position in relation to original insertion point(or something like that)? - this value is no longer used in the panel.
- 'frame_end' seems broken(not used in panel).
- If the Hold Offset Start is less than the start point of Strip Offset Start, and Strip Offset Start value is changes it will jump to zero, and if extended to the left the hold part of the strip will not be drawn, until the Hold Offset Start value is changed.
- The 'Strip Offset End' shows the number of frames to the end of the source material, this is not very useful in the UI. Ex. to get the strip end to extend to the right(make it longer) you'll have to drag to the left(opposite direction) to decrease the value.
- The Hold Offset Start/animation_offset_start seems completely off. It extends the strip in the end, not in the start.
- There are commented out hold frame duration values in the code.
- Several of the values can be illegal, causing the strips to turn the 'inside out".
- The panel titel "Timecodes" can be misleading - because often time codes means in most cases file embedded time codes. This panel is just Transform values written in SMPTE and frames - and not time codes.
We are hiding entries in strip menu based on selection. Should they be preferably grayed?
Sorry if this is the wrong place to write this, but in the markers menu->jump to next marker, previous marker should instead be in the view->navigation menu instead with the other jump to commands?
Sun, Jun 16
The contents of SEQUENCER_MT_change seems to have been moved into the Input menu in this commit: D2665
Sat, Jun 15
This is the width of the VSE sidebar panel from a build I downloaded 19/5 called blender-2.80.0-git.06c4139a6833-windows64:
This is not a bug, and not something that can be addressed with the system we have. The width of sidebars are constant, while the size of editors are relative to the window size. This means that the they will differ depending on the window size - at certain sizes they *will* be identical in width.
This has been fixed by D5065.
Thu, Jun 13
user has to save selection state, do stuff, and restore selection. Not a good practice IMO.
Wed, Jun 12
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:
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.
Pre 2.80 users could only import Movies through the Add menu and therefore they where always was exposed to the import options. With the file browser in the default VSE workspace missing the import settings, most people will never know the existence of them, causing a bad experience.
This is a usability issue, outside the scope of the bug tracker.
Proposals like this should explain the motivation (pros & cons).
What advantage does this have to rewrite these in another language?
This patch has been included in this more comprehensive timecode panel fix patch: D5065
Tue, Jun 11
Not what I had in mind (but good for a quick fix). That placeholder wouldn't be needed 99% of the time.
@Christopher Anderssarian (Christopher_Anderssarian)
I would agree with :FFF format for frame regardless of framerate. Each time I look at strip length now, I have to think about the format. But according to https://en.wikipedia.org/wiki/SMPTE_timecode, the format is HH:MM:SS:FF, which we are violating already.
@Jeroen Bakker (jbakker)
Thanks for reminding me of halide - forgot about that one.
What are the requirements of such a library. I would expect that headless rendering is one of those.
Did you have a look at Halide? https://halide-lang.org/
They promote them as a language, but actually is more a framework.
Just checked 2.73. Same bug.
Is this new issue?
I mean it should be easy to fix, but not sure if I should look for what caused this.