"Remove Overlaps" function: either I'm doing something wrong, or it's useless for me

Right-clicking an audio event that is overlapping another audio event, there is a menu “To front → Remove overlaps”. This removes the overlap of the selected event. As expected.

But: This doesn’t have a shortcut.

Instead there’s a shortcut for Audio → “Delete Overlaps”. When selecting an event that is in Front of another event, this function doesn’t do anything. When sending it to Back, then it will remove the overlap in the same manner as the right click option.

The problem is that the “Send to back” command automatically deselect the current event and select the Front event.

On top of that, I can’t find any way of toggling selection between overlapping events. Without sending it to either front or back.

The combination of these “features” makes it impossible to create a keyboard macro for “Remove Overlaps” to work as expected. This is an ESSENTIAL function when editing audio. If this function is overlooked, it’s almost a deal breaker for me even continuing using Nuendo.

The only workaround is to have two shortcuts for delete overlaps: one if you want to remove the overlap of the start, and another for removing an overlapping tail (using Navigate → Left/Right to select the rear event).

Help, please.

I’ve bypassed the function using a Keyboard Maestro macro, sending the event to back, clicking the mouse (that will be on top of the event as it has just been selected) then doing “Delete Overlaps”. It’s a blunt but currently working workaround.

Edit: Doesn’t work on MIDI Events. But “Right Click - Remove Overlaps” does. WHY doesn’t this have a keyboard shortcut? It would have solved everything.

1 Like

I’d love a keycommand for that too

How do you get the" remove overlaps" when you right click tho ?

WHY is this not fixed yet? It’s a simple Key Command. Just add it.

Right…

By the way, there’s another problem with overlaps. The option “show overlaps on mouseover” doesn’t work. You can see them at any time.

(N12)

Running into these issues in Cubase 13.020, would love to see a fix!

Possible solution: activate Preferences / Editing / Delete Overlaps

Essentially, with this preference active all overlaps automatically delete the portion of the event which is at the back when one event is dragged on top of another event. In other words, delete overlaps is on all the time for all editing. This may provide a workaround for the OP’s workflow, or at least help somewhat.

I’d rather keep my overlaps and have SB fix this problem. I don’t understand the delay in checking how the options work.

Me too - sometimes overlaps need to be adjusted after the event.

1 Like

I need control of the overlaps, so turning it of is not an option.

The system of comping without moving events up and down in the stack makes the [move to front] command weird and kind of redundant. It doesn’t really do anything anymore, or?

I like being able to comp without having to mute everything first and also that the active event is visible. So. the “new” system is better for me. But I don’t understand why they kept some of the old functionality, it doesn’t do what it did before.

best regards,
Johannes

It has nothing to do with comping. That’s for takes.

The use case is for sound design. Moving things around, slicing clips to fit them, to try things and sync things to picture. Ideally, there will be no overlaps, but it happens when working at a high pace.

As a result of the function not working properly, we have to spend valuable time going over all overlaps in all regions manually, sending to back/front or cut head/tail on individual regions. I’ve tried an advanced macro workaround, but it doesn’t always work. For a DAW that targets professionals, it’s a conundrum this has not been nailed yet.

Edit: Ah, I see you focused on the bring to front/back command.

In any situation where you’re not using comping, it’s necessary to determine which event is going to play back if there are overlaps. Front/back is the order of priority. And selecting ANY event - either front or back - in the situation of an overlap, the event in the back should always have the overlap removed. That’s why the way it’s designed now is pointless. There is no use case for removing the overlap of an event in the front, since you’ve already determined that you want that event to be played back.

As a workaround, you could try changing the workflow.

Instead of selecting either the front or back event, simply select both events and then Audio > Delete Overlaps.

Why not use the left / right arrow keys for a straight selection? Or use ‘Move Events to Back’ to toggle the ‘to front’ status of the overlapping events,

Does this really require a macro? Why not select all the events concerned, using ‘select all events’ on a track for example, followed by Audio > Delete Overlaps.

What is the precise step-by-step process of this workflow? What do you typically want to achieve for each edit? You could perhaps just select all events on the track and use Audio > Delete Overlaps.

Don’t get me wrong. I agree that having a key command for ‘Remove Overlaps’ might help in some cases and I certainly wouldn’t be against this if it was implemented by SB.

If you want to keep your overlaps then you can choose not to delete them - nothing obliges you to delete overlaps. If there is an overlap you will hear the event that is on top. If, after deleting an overlap, you want to later recover the audio that was underneath you can do so by extending the event. Deleting the overlap does just that, it deletes the overlap… it doesn’t delete the audio itself.

What is the precise ideal workflow you are expecting here?

Of course I know that audio isn’t dead behind the curtain, but that’s if there’s audio beyond the clip. In some cases, for example in the case of actual copy requested on a clip, the clip corresponds to the file level (there are other examples, such as the ends of an audio sequence). At this point, there can be no overlap. Consequently, the visible overlap becomes information (that the audio segment is wider than the clip - and even by how much - and therefore the possibility of widening it).

As written in the manual, this overlap should be visible at all times (which is a bit parasitic with slanted lines - in Pro Tools there’s just a gentle change in contrast, which is more acceptable to the eye), or only on mouse-over, which hasn’t worked for a long time.

Translated with DeepL Translate: The world's most accurate translator (free version)

@Mute sorry I’m none the wiser.

Could you perhaps translate that into a simple step-by-step procedure of what you expect Nuendo to do with regard to overlaps. Or are you simply saying that you want Nuendo to be Pro Tools in its way of dealing with overlaps?

I don’t know how to say it any better. Sorry about that. Otherwise, to put it simply: I’d like this function to be like the one advertised in the manual. See overlap on mouse-over. Do you know what I mean?