Just want to mention that Select Linked operator exists for other editors that have timeline, so it will have to be much bigger change. And while changing name is easy, operators are bpy.____.select_linked and those have to be changed too. Because if you have select_linked operator which selects adjacent, and select_something (because linked is taken) operator that selects linked its gonna get real confusing. Probably too much of a breaking change. I think its worth it personally, but will need lot of people to sign. Its gonna be painful but worth it in long run to have more clear UX and less confusing names.
2 Likes
While “link” is the NLE industry standard word for binding clips together, it’s also used all over Blender with different meanings, and trying to reserve it for binding VSE strips, with renaming and versioning everywhere else may too much of an uphill battle.
Looking at 3D objects, they’re “parented”, the selected objects to the active selected object. Moving the parent, the children will follow, but moving the children will not move the parent.
This concept is implemented in the VSEQF by SNU:
Ctrl+P for Parenting
Alt+P for Clear Parent
3 Likes
Currently, is there a “link” indicator of input strips of effect strips:
Ah, right, totally forgot about these, will definitely do this! Exact placement (before or after missing media icons?) can be the subject of an intensely heated debate later 
The operators I’m talking about are bpy.ops.sequencer.select_linked() and bpy.ops.sequencer.select_linked_pick(), their implementations are restricted to VSE code.
I’m not proposing to rename any of the other “select linked” operators; they make sense as-is IMO:
- Keyframes that are part of the same F-Curve remain part of the same F-Curve even when moving them around, so it makes sense to call these “linked”
- Same for grease pencil points that are part of the same curve, UV verts part of the same island, bones part of the same chain, etc…
- Two objects with the same material/mesh data/particle system etc. mean that changing the data on one changes for all of them, so it makes sense to call these “linked”
But strips that are next to each other aren’t linked in any of these senses.
Just proposing to rename the VSE-specific operators to .select_adjacent() and select_adjacent_pick().
I think the term “parented strips” would suggest a one-way connotation when in reality moving any linked strip will move all of them (similar to linked object data). In this sense I think the GSoC “linked strips” adheres more to the concept of “linking” in a general Blender sense than the previous naming (“linked” as “strips next to each other on the same channel”).
No, but I’ll see how it looks in combination with the link icon… seems like it would help a lot in the uncommon case that you have linked strips that aren’t just on top of each other (A/V)
1 Like
There is bpy.ops.action.select_linked() bpy.ops.nla.select_linked() and etc. For each editor. Each has its own operator. And they all do same thing. And you cant just rename one imo. Cant have same thing called different names in different editors. And renaming the bpy.ops name itself is breaking change (although welcomed by me)
I don’t think there’s a nla.select_linked, though, right? Unless I’m missing something. Can’t find that one in the operator search or any menus. Stuff like action.select_linked makes sense in that keyframes that are part of the same f-curve remain part of the same f-curve even when you move them around… As soon as you move strips so that theyre no longer directly bordering each other, you cant use the sequencer.select_linked or sequencer.select_linked_pick ops anymore, which doesn’t make too much sense… how are they “linked” then?
Versioning a change to the operator name is something I’m totally unfamiliar with so others could chime in on this point. If it is a breaking change that can’t be versioned we could see about just keeping the op name the same while changing the user-facing name. In my implementation so far there’s no separate operator for selecting linked strips, (you just select a strip that’s linked and it’ll auto-select all other linked strips), so there shouldn’t be too much confusion for scripters.
1 Like
Well, same argument can be made about VSE if we’re stretching definitions and we can say all strips are linked to the channel same way keyframes are to fcurve. But matter of fact is on user side they all do same thing - select keys/strips on a horizontal line. I don’t think user is looking into this much deeper than that. I agree that current term “Select Linked” is misleading for both usecases, because keyframes aren’t linked to the fcurve, they’re inside it, its completely different. That’s why I’m saying I would like to see this changed to adjacent everywhere, but anim-rigging module would have to be consulted about that.
1 Like
I would also say, that in Blender, for this feature word “parented” would be more appropriate, than “linked”.
In standard video terminology, a sound clip is not “parented” to the associated video clip. They are linked, or not linked.
2 Likes
In standard Blender terminology, objects that influence the transform of others are parented not linked.
Linked means something else.
So in this case it makes sense to use the terminology that is already used elsewhere in Blender even if it is not what is used in other programs.
But parenting is hierarchical tho, one is influencing other. In this case both are influencing each other. It feels more linked
6 Likes
Video and sound clips aren’t ‘objects in Blender’. They’re footage elements on a timeline.
1 Like
Yeah, but linked has a specific meaning. I think it requires a new term. Like “grouped”.
joined
attached
merged
How about “connected”, or ”entangled”?
When considering different names, the term would show up in menus as an imperative verb (e.g. “link/unlink”) and not a participle (“linked”), so whatever sounds best as a verb in the present tense would be great.
- Join/Separate
- Attach/Detach
- Merge/Unmerge
- Connect/Disconnect
- Entangle/Disentangle
- Group/Ungroup
- Bind/Unbind
I like 1 since “linking strips” in the industry NLE sense is a little like joining together objects in Blender – when you move one part of the object the other parts move with.
I also like 2, 4, and 7, let me know what you all think
3 Likes
Entangled is exactly spot-on in terms of meaning, but might be a little obscure
After some conversations with Dalai, Pablo and Sergey, there is consensus that “Connect/Disconnect” is the preferred naming. It’s important to keep the meaning of “linking” consistent in Blender, more than aligning with the standard terminology used by other video editing software in this case.
15 Likes
When going over the Retiming implementation, did you find a good reason to have 3 places to switch it on/off: in the Time panel, in the Overlay drop down and on the Retime menu?
Seems to be overkill, and the source of confusion. Imo, it should not be exposed in the Time panel(which is for time related values), and not exposed in the Overlay drop down (which is for info related overlays, and not for interactive widgets).
3 Likes
I’ll have to speak w/ @iss about changing this (since afaict he added these options), but the option in the Time panel and Retime menu do the same thing – to disable/mute retiming editing. The one in the Overlay dropdown is different, it hides the keys altogether.
I agree that the Time one should be removed, but I think the Overlay option is good to stay as long as the current behavior of the Time/Retime option remains the same, since otherwise there’s no way to hide retiming keys.
2 Likes