Item content drag destroys fades

[cohler]

Dragging an item's content (using the "Move item contents" mouse modifier actions) destroys both crossfades (at start of item and end of item) with global option auto-crossfade on. When auto-crossfade is off, it works correctly.

Dragging the content of an item should have no impact on the fades at either end independent of the auto-crossfade setting. One has nothing to do with the other. Auto-crossfade should apply only to when you are moving the item itself when dragging it, not when you are moving the content of the item.

One needs to be able to move the content of items to adjust crossfade join points (as shown in the video) and the status of auto-crossfade has nothing to do with that, because the item itself is not being moved.

See video below which first shows the correct behavior with auto-crossfade off and then the incorrect behavior with auto-crossfade on.

@Justin and @Schwa can this be fixed?

[Fabian]

It doesn't seem to behave that way here


I have the auto-crossfade option on, and I slip-edit (Alt+drag on Windows) first with both items selected, and then with only the left item selected. It seems to work as expected. Not...?

[cohler]

Originally Posted by Fabian

It doesn't seem to behave that way here


I have the auto-crossfade option on, and I slip-edit (Alt+drag on Windows) first with both items selected, and then with only the left item selected. It seems to work as expected. Not...?

That's totally different from what I reported.

First, you have default, symmetrical fades.

Second, you have multiple items selected.

The error as I reported and demonstrated occurs when you have non-default fades and you move the contents of an item as described with auto-crossfade on.

The item drag reverts the fades at both ends back to default (7). Since your example starts with default it wouldn't show anything anyhow.

Another difference is that I am using the "Move item content and right edge with ripple" command. You are not in your example.

[Fabian]

Originally Posted by cohler

That's totally different from what I reported.
<snip>

Then I misunderstood. Sorry.

[cohler]

Dragging an item's content (using the "Move item contents" mouse modifier actions) destroys both crossfades (at start of item and end of item) with global option auto-crossfade on. When auto-crossfade is off, it works correctly.

Dragging the content of an item should have no impact on the fades at either end independent of the auto-crossfade setting. One has nothing to do with the other. Auto-crossfade should apply only to when you are moving the item itself when dragging it, not when you are moving the content of the item.

One needs to be able to move the content of items to adjust crossfade join points (as shown in the video) and the status of auto-crossfade has nothing to do with that, because the item itself is not being moved.

See video below which first shows the correct behavior with auto-crossfade off and then the incorrect behavior with auto-crossfade on.

@Justin and @Schwa can this be fixed?

[joshxtra]

I never noticed this, but it should definitely get fixed! A short description of the bug could be:

Overlapping fades get reset by item-content-drag if autocrossfade is enabled.

[cohler]

Originally Posted by joshxtra

I never noticed this, but it should definitely get fixed! A short description of the bug could be:

Overlapping fades get reset by item-content-drag if autocrossfade is enabled.

Yup, and an even shorter description is the thread title that I created, "Item content drag destroys fades"

[cohler]

Are there any plans to fix this bug? @Justin @Schwa

[cohler]

Will we ever get ANY RESPONSE of any kind to this MAJOR BUG?

[cohler]

The recent bug fix

+ Media items: preserve manual fade shape when clearing auto-crossfade [t=240579]

fixes the problem of fade curve shapes reverting.

It DOES NOT, however, fix the bug that still causes the fade lengths on asymmetric fades to change so that they are no longer asymmetric, ie it sets both the fadein and fadeout lengths to be exactly equal to the time between the beginning of the fade out and the end of the fade in. See p=2318985

[akademie]

I don't have that problem in REAPER v6.10 32bit on Windows10 x64.

It's working correctly here (no fade type etc. resetting) while moving contents of anyy of the overlaping items either with the Auto cross-fade option On or Off.

[cohler]

Originally Posted by akademie

I don't have that problem in REAPER v6.10 32bit on Windows10 x64.

It's working correctly here (no fade type etc. resetting) while moving contents of anyy of the overlaping items either with the Auto cross-fade option On or Off.

NOT working here. As I said, the fade types don't reset, but the fade lengths DO.

REAPER v6.19 64bit on OS X 10.13.6

[akademie]

Screencapture of mine

Auto crossfade ON, Mouse modifier set to "Move item contents and right edge ignoring snap, ripple edit later items".
(Win10 x64, REAPER v6.19 x86, also 6.17rc1 x86)

[cohler]

Originally Posted by akademie

Screencapture of mine

Auto crossfade ON, Mouse modifier set to "Move item contents and right edge ignoring snap, ripple edit later items".

Those are NOT asymmetric fades. In other words, the beginning of your fade out = the start of the 2nd item and the and the end of your fade in = the end of the first item. If you try it with ASYMMETRIC fades, you will see the behavior I described.

[akademie]

Originally Posted by cohler

Those are NOT asymmetric fades. In other words, the beginning of your fade out = the start of the 2nd item and the and the end of your fade in = the end of the first item. If you try it with ASYMMETRIC fades, you will see the behavior I described.

OK man, upload the example project (without media), please.

[cohler]

Originally Posted by akademie

OK man, upload the example project (without media), please.

It doesn't matter what the project is. It happens in ALL cases when set up as I described.

1. Asymmetric fades
2. Auto-crossfade on
3. Move item contents

That's it. Try it on your system with asymmetric fades and you will see.

[akademie]

Originally Posted by cohler

It doesn't matter what the project is. It happens in ALL cases when set up as I described.

1. Asymmetric fades
2. Auto-crossfade on
3. Move item contents

That's it. Try it on your system with asymmetric fades and you will see.

That's why I asked you for example project, because I don't know what you mean by asymmetric fades and how to create them. That's it.

I would think that it is not a big problem to upload mini project to showcase problem, if others try to help. Sure it is as it seems

EDIT: maybe I found it - is it the point handle where fade in/out crosses to move to create asymmetry? if yes, then it is still working correctly, not touching fade lengths..

[cohler]

Originally Posted by akademie

That's why I asked you for example project, because I don't know what you mean by asymmetric fades and how to create them. That's it.

I would think that it is not a big problem to upload mini project to showcase problem, if others try to help. Sure it is as it seems

That's why I uploaded a LICEcap showing exactly what I mean. Once again an asymmetric crossfade is one where:

1. Either the fade-out and fade-in lengths are DIFFERENT, or
2. The fade-out doesn't start at the same place where the 2nd item starts, or
3. The fade-in doesn't end at the same place where the 1st item ends.

As you can see clearly in the LICEcap video.

The fades that you show have equal fade-in/fade-out lengths, the fade-out starts at same place as the beginning of the 2nd item, and the fade-in ends at the same place as the end of the 1st item.

Do you understand what I'm saying? If you still do not, I will be happy to upload a small project.

[akademie]

Originally Posted by cohler

...<snip>
Do you understand what I'm saying?

Let me tell you, that I am really sad with your attitude
Keep repeating yourself with licecaps etc.
I am not gonna argue if you do not want to accept any help.

It looks like you have some configuration broken at yoour end, or it is Mac specific bug.

EDIT: Maybe someone could meet at Zoom...

[akademie]

OK, I managed it, with Auto crossfade OFF, because when on, I cannot create asymmetric crossfades, of course.
So then it works (I mean moving contents) ok when Auto crossfade is OFF.
Confirming the behavior you talk about when Auto crossfade is ON.

[schwa]

Fixing, thanks for the report.

[cohler]

Originally Posted by akademie

Let me tell you, that I am really sad with your attitude
Keep repeating yourself with licecaps etc.
I am not gonna argue if you do not want to accept any help.

It looks like you have some configuration broken at yoour end, or it is Mac specific bug.

and

Originally Posted by akademie

OK, I managed it, with Auto crossfade OFF, because when on, I cannot create asymmetric crossfades, of course.
So then it works (I mean moving contents) ok when Auto crossfade is OFF.
Confirming the behavior you talk about when Auto crossfade is ON.

Yes, of course auto-crossfade must be off to create asymmetric fades. I never said it didn't.

My report was specifically and explicitly about when you already have asymmetric fades, as I clearly stated and showed in LICEcap. I said (emphasis added):

"It DOES NOT, however, fix the bug that still causes the fade lengths on asymmetric fades to change so that they are no longer asymmetric, ie it sets both the fadein and fadeout lengths to be exactly equal to the time between the beginning of the fade out and the end of the fade in. See p=2318985"

I don't appreciate the condescension. What I reported was precise and complete.

[cohler]

Originally Posted by schwa

Fixing, thanks for the report.

Thank you!