Crossfade bug in DP 10 & 11

[jimmy330]

This is a verifiable bug in both versions. Here's the scenario: In graphic edit, take a soundbite, do a split, Time Stretch the end of one split, try to do a cross fade with the "un-stretched" soundbite. What happens is there will be only 1 handle visible, so the cross fade will jump to ONLY one soundbite! The work around is you have to manipulate "Edge Edit" until you see the required 2 square handles on each corner of joining soundbites. PLEASE fix this bug soon!!!

[HCMarkus]

I believe this is because, when a soundbite is time-stretched, a new copy is written that includes ONLY the stretched segment. As such, there is no time-stretched data to cross fade out of. This can be avoided by stretching an area slightly longer than the specific audio required, then trimming back into the stretched soundbite, thus giving room for the fade.

I suppose MOTU could add a user-specifiable "automatic extension of stretch area" parameter; doubtful many would want time stretching to be applied to a whole audio file any time a small segment is stretched... it would be a CPU hog.

[muscletn]

I too, have been experiencing this issue. It didn't happen until DP10. I just recently went from 9.52 to 10.13. I routinely time-stretch, and never had to deal with it until now. Maybe because the new "improved" time-stretch coding?

[bayswater]

Maybe this is a case where the stretched audio should be rendered first?

[muscletn]

I'm not sure what you mean by "rendered first." Please explain.

[bayswater]

Bounce, merge, something to turn it into file that plays without stretching or other processing.

[muscletn]

Aha. I guess that's what Jimmy330 is doing by manipulating the sound bite until both handles appear. My workaround is to "pull" the unstretched" audio slightly over the stretched audio. Rendering by a different name?
Again, the appearance of this issue struck me as a What the heck? as I'm new to DP10.13. I've been doing this for years in earlier versions, where putting in a crossfade was never a problem.

[tommymandel]

I believe this is because, when a soundbite is time-stretched, a new copy is written that includes ONLY the stretched segment. As such, there is no time-stretched data to cross fade out of. This can be avoided by stretching an area slightly longer than the specific audio required, then trimming back into the stretched soundbite, thus giving room for the fade.

Thanks, HC! That explains something I've been wondering about since DP10. PS: I gotta say I love the transparency feature that 10 added when dragging bites, so you can see where you're going!

[stubbsonic]

Whenever I do a time-stretch on a soundbite and I know I'm going to crossfade it later, I aways drag the edge to reveal more of the soundbite before I do the time-stretch. Then I have that extra bit to work with.

If we're understanding it right, it's not a bug, it's just how tIme-stretch works.

[muscletn]

Here's the latest wrinkle in what I believe is probably a related issue. I do a good amount of destructive plugin work on any given track. For example, I'll want a tremolo to come in just at the end of a phrase for dramatic effect. Before DP10 I would highlight the desired area, navigate to the "Apply Plugin" setting, choose the plugin, audition it, and then apply it. The plugin effect is now waiting for me to apply the necessary crossfade, and my work is done.
Now, with DP10.13 the same procedures are followed, but after applying the plug in, Fades NOT Crossfades are already applied. And, they're not in the right place!
I have photos of before and after but I can't find the upload link for them. Please advise.

DP10.13, 12-core MacPro 3.46, OSX 10.12.6, UAD Apollo

[bayswater]

Here's the latest wrinkle in what I believe is probably a related issue. I do a good amount of destructive plugin work on any given track. For example, I'll want a tremolo to come in just at the end of a phrase for dramatic effect. Before DP10 I would highlight the desired area, navigate to the "Apply Plugin" setting, choose the plugin, audition it, and then apply it. The plugin effect is now waiting for me to apply the necessary crossfade, and my work is done.
Now, with DP10.13 the same procedures are followed, but after applying the plug in, Fades NOT Crossfades are already applied. And, they're not in the right place!
I have photos of before and after but I can't find the upload link for them. Please advise.

DP10.13, 12-core MacPro 3.46, OSX 10.12.6, UAD Apollo

I'm also seeing crossfades in what seem to be the wrong place. I'll have to look more closely but something doesn't look right.

[stubbsonic]

It would be good to start a support ticket on this one. Seems like a new bug they should fix quickly. Get some screen shots a good example project and get on there with MOTU support.

[bayswater]

So does this capture a Bug or a Feature? (This applies to both DP versions 10.13 and 11.00)

1) Record a mono audio signal for a few seconds
2) Use the cut tool to slice the soundbite in half
3) Grab the crossfade doodads in the soundbite display, where the halves connect, in either soundbite, and drag them to make a crossfade.

You get a cross fade that straddles the cut made in step 2.

Do the above three steps but overlap the two halves of the soundbite. Same result.

Now do it all over again like this:

1) Record a mono audio signal for a few seconds
2) Use the cut tool to slice the soundbite in half
3) Process the second half. Stretch it, apply a plugin, whatever.
4) Butt the two halve against each other.
5) Grab the crossfade doodads in the soundbite display, where the halves connect, in either soundbite, and drag them to make a crossfade.

You get a cross fade that initially straddles the cut made in step 2, but then jumps to the right to start in the second half. The fade out part of the crossfade is happening at the start of the second half as is the fade in.

Do the above three steps but overlap the two halves of the soundbite. Same result.

After Step 3, merge the processed half, or bounce and import, etc. Proceed with the rest of the steps. Same result. Overlap by any amount and get same result. Adjust the crossfade -- while adjusting, it moves to the left to straddle the border between the soundbites then afterwards jumps back to the right.

Note that in the second instance, I not only processed a little more than I planned to crossfade, I processed all of the second half of the original soundbite so that the crossfade only applied to maybe 10% of it.

Note that in the last example the second Soundbite is not even processed any more. It's, as far as DP is concerned a simple raw audio file.

If this is a feature and not a bug, what is the purpose of the feature? There appears to be no way to start the fadeout in a crossfade somewhere in the soundbite to the left.

[stubbsonic]

I was referring to crossfades being "in the wrong place" not the inability to crossfade data that does not exist.

[bayswater]

I was referring to crossfades being "in the wrong place" not the inability to crossfade data that does not exist.

That's what the above gives you if you overlap the soundbites. The crossfades are in the wrong place.