I agree that this is better, I reported this as a bug years ago but it was closed saying its a feature.

But the complexity this adds for new users is not worth IMO

I didn't analyze the code in depth, but optionally I would do something like this:

if (seq1 != NULL && seq2 != NULL && seq1->startdisp >= seq2->startdisp) {
  seq->seq1 = seq2;
  seq->seq2 = seq1;
}
else {
  seq->seq1 = seq1;
  seq->seq2 = seq2;
}
seq->seq3 = seq3;

This seems very useful for generator strips (where the multicam selector is kind of like a generator)! Overall, I like the idea, but I'm not sure how some edge cases would be handled. (My apologies if you're still working on the edge cases and this is unfinished!)

I applied the patch to the latest daily build and have some feedback:

Contents:

1. Order - thank you!
2. Behavior on deleting the single-channel strip
3. Dealing with soft and hard splits
4. Found a bug
5. Alternate way to solve problem of zero-length strip?

1

So in order to make this input assignment "just work", this patch bases the input assignment on position:

Thank you!!! The "order of selection" behavior caused me major confusion over the summer. I think this could be separated from the quick-add-1-second-cross patch and added next release cycle!

2
One thing I like about the sequencer is that everything that happens is represented as a strip without changing previous strips: for example, effect strips are separate from the input strip.

When adding a transition to two strips with no gap in time, an invisible transition of zero frames duration is added. This is neither very useful...

I agree that an invisible zero-length transition is weird. I think it is weird because it goes against the idea of effects strips being visible in the sequencer.

One problem that happens as a result of the single-channel transition is that if I:

1. add this "1-second shortcut" transition
2. then delete the effect strip
3. there is a gap between the strips where the transition used to be.

This feels like a violation of the non-destructive nature of editing and could be a reason single-channel transitions are not endorsed.
Possible solution to 2: put the transition effect in the next available channel instead of replacing the existing strips. This would also require moving the handles of the strips around automatically and moving one of the strips to a nearby channel.

3

it is not officially endorsed to do transitions in a single channel, because it might cause an image freeze during the transition

Just to make sure I understand, by "image freeze" do you mean holding the (last | first) frame of the (previous | next) strip? I tried using the quick-add effect on "hard-split" versions of your helpful timecode movies and the end frame does "freeze"/"hold" after it runs out.

The following might be a different issue:
Another question is what should be done with strips that have been "soft split" - should the transition automatically play frames from the split region or freeze on the last available frame? If I soft-split your timecode strips, I see that it automatically moves the strip handles, but is that what the user would want? There should be a way for the user to override the "quick-effect" version.

Perhaps a solution could be to add another condition to when to apply the quick effect: no time gap AND no ambiguous cases of what frames to display (this seems hard to define).

4 Found a bug:

1. Add two adjacent color strips
2. Add the 1-second cross effect
3. Select and "hard-split" (shift K) either color strip
4. Notice that the automatically-added cross is now tracking the part of the strip that is farthest from the place the cross happens.

5: Alternate solution?
Maybe there is a better way to show a zero-length strip as a way to prod the user into overlapping strips before applying the transition effect? I tried making a mockup here with a small label that appears floating next to the strip. The idea is it would expand as the transition effect strip expands

This becomes complicated in cases where there are lots of strips crowding it but I imagine we could make some indication (maybe a shadow) and have rules to decide which side of the frame to display the label on.

Problems with this mockup: no plan for what to do when you zoom out --> maybe there would be an "effective size"?

@Corwin Kerr (ckerr) Thank you for your comments. I replied on https://blender.chat/channel/vse?msg=o7CmEzzcAC7pL4K5L

In following file there are 3 possible transitions where strips overlap, last 2 are covered, but first one isn't because both strips start at same frame.
So logic there would be that if strips start at the same frame, transition should be done from strip that ends first to strip that ends last.

Since I am cross-checking myself if I am thinking correctly here, I may as well post my version where these inlines should be resolved - P2053
Maybe a bit more changes but for the better I would say :)

Just some notes mainly to myself:
Creating strip with 0 length is very bad and it is a bug. This applies to all 2-input effects, so there is no point fixing it here.

Seq1 / seq2 swap should be done to load_data.effect.seqx as operators shouldn't modify seq directly unless it is absolutely necessary. It is not easy to do without interrupting logical flow however.

Ideally both cases would be sanitized in seq_effect_find_selected(). however there is also logic that relies on strip that will be created with 0-length. That means that both cases must be sanitized in operator or SEQ_add_effect_strip(). Loading functions doesn't provide error messages, so right now operator seems to be a place where this should be done, but in the future this should be done for RNA as well, so it should be a core feature.

Seems to work fine. I still don't usnderstand why you need to set length to effect as I asked in 4th inline comment. It seems to works fine without that.

I have noticed, that this can cause glitch when strip has already effect. In that case you have to call SEQ_time_update_sequence for all strips that are connected to seq1 and seq2. Not sure why there still isn't is_effect_of function... I may add one so it can be used here.

In D10207#341390, @Richard Antalik (ISS) wrote:

Seems to work fine. I still don't understand why you need to set length to effect as I asked in 4th inline comment. It seems to works fine without that.

I have noticed, that this can cause glitch when strip has already effect. In that case you have to call SEQ_time_update_sequence for all strips that are connected to seq1 and seq2. Not sure why there still isn't is_effect_of function... I may add one so it can be used here.

I'm fine with you doing those minor changes, if you feel it is ready to be committed.

In D10207#341486, @Peter Fog (tintwotin) wrote:

In D10207#341390, @Richard Antalik (ISS) wrote:

Seems to work fine. I still don't understand why you need to set length to effect as I asked in 4th inline comment. It seems to works fine without that.

I have noticed, that this can cause glitch when strip has already effect. In that case you have to call SEQ_time_update_sequence for all strips that are connected to seq1 and seq2. Not sure why there still isn't is_effect_of function... I may add one so it can be used here.

I'm fine with you doing those minor changes, if you feel it is ready to be committed.

Yes, I will have to do it separately as cleanup commit.