fade behavior DP 10.01

[csavetman]

According to Motu
• If you delete the end off a soundbite with a fade, the fade is preserved. This behavior more closely matches DP 9.

However, I'm finding that when deleting the end of a soundbite with a fade on it:
instead of keeping the beginning anchor point of the fade in place and just shortening the fade, DP now moves the start of the fade earlier, in order to keep it the fade the same length as it was before the edit.

I'm not sure if that is what they were going for, but I seem to remember DP9 would keep the start of the fade "locked" in place, and just adjust the end of the fade accordingly.

Carlos
DP 10.01
Sierra 10.12.6

[dix]

Oh hey, you’re right. I suppose there might be situations out there where this behavior is better, but I’m used it the way it was in 9. I wonder if they made it like this intentionally. ...watch. I’ll get used to it this way and then they’ll fix it back to how it was.

[Timeline]

It's not correct. It should at least allow you to move the fade over the cut point and not force it to the front or back. The way it is, is problematic and could leave pops. See my post on this as any use of Audio pulldown menus where creation of soundbites exist makes them incompatible and they remain corrupted in your file and will not work with any original soundbites where crossfades are required.

[csavetman]

Oh hey, you’re right. I suppose there might be situations out there where this behavior is better, but I’m used it the way it was in 9. I wonder if they made it like this intentionally. ...watch. I’ll get used to it this way and then they’ll fix it back to how it was.

I spoke to someone at Motu tech support yesterday. He said it was actually a pretty heated debate internally concerning the fade behavior update. He suggested they might be up to adding a preference setting update in DP to address this.

Carlos

[mikehalloran]

instead of keeping the beginning anchor point of the fade in place and just shortening the fade, DP now moves the start of the fade earlier, in order to keep it the fade the same length as it was before the edit.

That's exactly the way it works in 9.52 for me. I just remastered a box set and did over a hundred of those end fades. I shortened the tails using edge edit and the fade moved with the edit.

I did not highlight and delete a portion of the tail—perhaps it behaves differently then? I suppose I can test and see later today. Let's hear it for Revert to Saved.

[dix]

Oh hey, you’re right. I suppose there might be situations out there where this behavior is better, but I’m used it the way it was in 9. I wonder if they made it like this intentionally. ...watch. I’ll get used to it this way and then they’ll fix it back to how it was.

I spoke to someone at Motu tech support yesterday. He said it was actually a pretty heated debate internally concerning the fade behavior update. He suggested they might be up to adding a preference setting update in DP to address this.

Carlos

Interesting. We don't often hear about internal deliberations. Somehow a "heated debate" among MOTU workers about fade behavior doesn't sound like it would be too intense.

A pref would be cool. Fade behavior doesn't get me too heated up, but I've seen that it's major part of some users workflow.

[csavetman]

instead of keeping the beginning anchor point of the fade in place and just shortening the fade, DP now moves the start of the fade earlier, in order to keep it the fade the same length as it was before the edit.

That's exactly the way it works in 9.52 for me. I just remastered a box set and did over a hundred of those end fades. I shortened the tails using edge edit and the fade moved with the edit.

I did not highlight and delete a portion of the tail—perhaps it behaves differently then? I suppose I can test and see later today. Let's hear it for Revert to Saved.

Yes Mike, you are correct. With edge edit, the fade does move with the edit. I was referring to the latter method-highlighting and deleting a portion of the tail. That's the one that seems to have changed from DP9.52

Carlos

[mikehalloran]

Thanks for the clarification, Carlos.

[Prime Mover]

I spoke to someone at Motu tech support yesterday. He said it was actually a pretty heated debate internally concerning the fade behavior update. He suggested they might be up to adding a preference setting update in DP to address this.

Hallelujah!!! DP8 fade behavior for me, thanks!

I will write a tech note asking for this preference. I know lots of you prefer the DP9 behavior, so I wouldn't ask for them to change it universally, but a preference would be AWESOME!

To me, snipping content means wanting to redefine a different fade, not leaving DP to try and guess what to do, so i'd rather the fade just disappear completely so I can select and Ctrl-F a new fade.