When editing inside of meta strip, use it's range to navigate to start
or end frame. When custom preview range is used, use this range
instead.
Details
Diff Detail
- Repository
- rB Blender
- Branch
- end_point (branched from master)
- Build Status
Buildable 17619 Build 17619: arc lint + arc unit
Event Timeline
@Sergey Sharybin (sergey) Do you think this makes sense as far as implementation is concerned? It's not nicest, but didn't want to spend too much time on this.
Comments are mainly to explain WHY's not WHAT's. And this is going back to a design of the change. What is it you're achieving with this change? Why is it only needed for jump operator but not for playback? What if preview is "wider" than the meta strip?
| source/blender/editors/screen/screen_ops.c | ||
|---|---|---|
| 3016 | From the code it s rather clear that metastrip time is used if SCER_PRV_RANGE is not used. But from neither the code nor comment it it is clear why this is needed. | |
This was requested feature and I thought it is good idea to respect meta strip range. It could be implemented for playback too perhaps, but I don't think that is very good idea. You can have much longer content inside meta and there I think it is important to be able to scrub and play it freely. But if you need to align something with meta start or end frame this change would allow to set frame and snap content to frame.
What if preview is "wider" than the meta strip?
It will behave in same way as if preview range is wider than scene range - it will use preview range. I understand it as preview range is overriding "normal range", therefore I want to modify only "normal" range.
This was requested feature and I thought it is good idea to respect meta strip range
Where the request is coming from? Where is (even a brief) description of how the interaction is supposed to work?
It could be implemented for playback too perhaps, but I don't think that is very good idea. You can have much longer content inside meta and there I think it is important to be able to scrub and play it freely
Playback and scrub are using different limits. I.e. in animation scene you can scrub to any (non-negative by default) frame, but playback will be limited by scene/preview frame range.
It's from T91403. Not sure if that is much more descriptive.
It could be implemented for playback too perhaps, but I don't think that is very good idea. You can have much longer content inside meta and there I think it is important to be able to scrub and play it freely
Playback and scrub are using different limits. I.e. in animation scene you can scrub to any (non-negative by default) frame, but playback will be limited by scene/preview frame range.
I know and I don't think this behavior is necessarily good for meta strips. But I don't use metas often personally, so it could be acceptable.
I see.
Wouldn't mind to quickly run this by @Francesco Siddi (fsiddi).
As for the implementation it seems that currently the jump will be limited to meta strip even when used outside of VSE. Imagine you open VSE, go into metyastrip, then switch to a Viewport and try to use jump. The meta strip bounds are to be ignored in this case I think.
It is a bit annoying to have are-specific code in the generic operator, but also not really sure it's better to introduce jump operator in the VSE. @Campbell Barton (campbellbarton) , do you have strong opinion here?
Yes, I see this issue, but it's easy to rectify.
It is a bit annoying to have are-specific code in the generic operator, but also not really sure it's better to introduce jump operator in the VSE. @Campbell Barton (campbellbarton) , do you have strong opinion here?
I haven't mention in commit message anything, but I did search for this operator in IDE and it showed only CLIP_OT_frame_jump so I thought that for VSE I would rather modify global one if it requires simple change. Now I see there are more of these not only for movieclip editor, so I would have added VSE specific one if I knew...