[Solved, But Introduces Other Issue] Cut special, Delete Hole?

You know I tried to use it the other day and it failed to work for me too. I was in a hurry so I didn't dwell on it and performed the task in a manual way. But now that you mention it, it should have worked.

Ah, that fixed it, thank you Brundlefly.    How in the world do these preferences keep getting set?   I would never have intentionally set that one.    For others, it's in preferences, but it's not under midi, and not under project -- see "Customization - Editing".   Grr.
 
Sorry I didn't remember the same problem from earlier.   I'm sorry to say there are so many little problems like this, and as I get faster and faster at just groaning and working around them, I try to move on and not get distracted from music by irritations with software. 
 

Anderton

Sanderxpander
I think it doesn't work when there are midi clips and does work if you split and delete those first. Which is dumb.

I checked, and that's close. It works as expected with audio, but with MIDI, deletes what's in the MIDI clip but doesn't close up the hole. Seems like a bug to me.
 
The workaround is if you select all and split at the beginning and end of the region to be cut, then drag that region in the timeline and cut special, it works as expected. You don't have to delete the MIDI clips first.

No, not a bug. Uncheck Preferences/Customization/Editing/MIDI/Non-destructive MIDI editing. 
That will do the trick.
 
Jerry

Thank you! Ya learn something new every day.

I marked this "solved." Just to check, I searched on: 
 
Sonar delete hole [solved]
 
...and found the following threads, all of which mentioned disabling Non-Destructive MIDI Editing as the solution.
 
http://forum.cakewalk.com/Solved-How-to-delete-a-section-of-a-midi-song-including-the-hole-m2956892.aspx
http://forum.cakewalk.com/Solved-Delete-Hole-Not-Working-in-X3e-m3021979.aspx
 

ampfixer
There's something about NDME that seems broken. I've had to turn it off to solve drag and drop issues and life is much better now. I'm treating it like the 64 bit double precision setting. Turn it off and forget about it.

Can you be more specific about the issue? Multiple people in multiple threads since X2 have said that unchecking Preferences/Customization/Editing/MIDI/Non-destructive MIDI editing causes delete hole to work as expected; none of the people in the threads I checked returned to the thread and said they were wrong, and I've confirmed it by trying it multiple times. So if there's a problem, it seems like it would relate to some other aspect of the operation than selecting a region in the timeline and deleting the hole.

The only threads I looked at were ones that referenced the OP's problem of delete hole not seeming to work properly. So correct me if I'm wrong, but my takeaway from what you're saying is that the delete hole works properly if NDME is disabled, but this simultaneously causes major problems with dragging MIDI clips if they touched each other. Do you know if this has been reported to CW?
 
Edit: I just checked and saw exactly what you're talking about with dragging. However, delete hole works expected if NDME is disabled. So...it seems the current options are: 

• Check NDME, not have dragging problems, but have to split at region boundaries prior to delete hole.
• Uncheck NDME, have delete hole work as expected, but have anomalous/unpredictable behavior when dragging.

Is this correct? That's how it's working here.
 
 

 
 
In general, creating clip overlaps by dragging clips in the parent track should and will create new lanes to resolve the "collision", regardless of the status of NDME.
 
When overlaps are created by dragging in lanes, the collisions will be resolved by cropping the clip in the 'landing" zone to make way for the moved clip. If NDME is enabled, the cropping is non-destructive (i.e. cropped out notes can be recovered by slip-editing the clip boundary back out). If NDME is disabled, the notes will be destructively removed from the clip (but as noted above, you may have to Apply Trimming manually).
 
AFAIK, this all pretty much works as designed. That said, I know of a several other things that work differently/unexpectedly/unintuitively/incorrectly, depending on the status of NDME. One was fixed fairly recently (terminal controller events not preserved when copying or bouncing clips with NDME disabled).
 
In general I find that MIDI editing is most intuitive and the results are most musically useful when NDME is disabled. But any time I encounter an unexpected result when moving/copying/pasting/groove-clipping MIDI, I retry with NDME in the opposite state, and usually get what I want.
 
 

I don't understand the idea that this is "working as intended". If a feature says "Non-destructive MIDI editing" that should in no way imply "cannot delete holes". The help description is vague but implies that you should be able to slip-edit clips without losing data, just like with audio, and that's about all it should change. Is there any good reason, apart from to work around this bug, where people would not want MIDI clips to act exactly the same way as an Audio clip?

I see what you're saying, that it shouldn't delete MIDI data if I've asked for non-destructive MIDI editing, but it's not like it'll prevent me from deleting a MIDI clip any other time, even with that setting on. If I choose to delete an area that contains MIDI then I just have to accept the consequences. Ideally the algorithm should slip-edit any clips that extend beyond the area to be deleted (thus preserving their data for later) but completely remove clips that fall entirely within the zone. It could even pop up a warning box about this, listing any clips that will be deleted that don't appear elsewhere in the project.