Not sure if I'm doing right, but when copying entire sections of a song when arranging, for example moving a chorus, the delete hole works but only shifts the tracks that have audio or midi in them. Tracks that are empty do not get shifted back and consequently the audio/midi data that appears later in the track, after the blank section, doesn't get moved back after deleting the hole.

Correct.
 
Delete hole only works when there's data in the hole

MagicMike
Not sure if I'm doing right, but when copying entire sections of a song when arranging, for example moving a chorus, the delete hole works but only shifts the tracks that have audio or midi in them. Tracks that are empty do not get shifted back and consequently the audio/midi data that appears later in the track, after the blank section, doesn't get moved back after deleting the hole.

@MagicMike
  Delete Hole stopped working correctly for MIDI clips in the Lexington release.  I submitted Problem Report CWBRN-49873 on 4/24/2016 that still remains at a "New" status.  A thread concerning the Delete Hole problem is here: http://forum.cakewalk.com/FindPost/3404822.
 
I sent an email to support yesterday, 6/08/2016, to inquire about the problem report status and hope to hear back in the next few days.
 
Hope this helps,
-- Ron

Thanks. For a workaround I placed copies of audio data into tracks with no data so I could move everything along later in the project.

Apparently they are in the process of developing something called ripple editing. It is supposed to take care of problems related to holes in the timeline. That's all I got.

Still haven't fixed this, huh? I'm using Kingston version because of this. Submitted a ticket months ago with no answer from Cakewalk folks. I'm getting close to dumping the software because of their lack of support, accountability, and simple acknowledgement of an issue. Frustrating.
 
Maybe the new owners will begin to care about their user base instead of sending out emails to re-up after I just did.
 
As I said, frustrating. Now, it seems, they've removed the ability to review submitted support tickets? Is this so?
 
Frustrated in St. Louis...
Wally

There's not a lot of incentive to fix this issue now, because they're working on replacing the delete hole/insert/remove measures functionality with true ripple editing. So it would be a fair amount of effort for something that would be obsolete not long afterward, and would delay implementing the improved way of dealing with arrangement-related editing.
 
There are a number of ways this kind of editing could be improved, so I think it makes sense to take care of them all at once.

Shouldn't have been broken in the first place. I can't believe more users don't have a problem with this. Seems simple enough. find the code in Kingston, compare to the later versions where it broke, replace the broken code with Kingston (working) code. Besides the fact that this was broken, what, 2-3 versions ago?
Apologies for venting to you Craig, but you're representing Cakewalk at this point. If I neglected my clients in this manner (5-6 months and counting), I'd have no clients.
Will they provide refunds for unused versions on my subscription? Kinda sucks that in changing the purchase model to provide all kinds of cool updates, etc., they've dropped the ball.
 
Anyway, holding out hope...

I am in total agreement with both Anderton and wtreppler. 
It should not be broken.
Better to spend the effort on a better way to do the same (or very close to the same) thing. 

wtreppler
Shouldn't have been broken in the first place.

 
I agree.
 

I can't believe more users don't have a problem with this. Seems simple enough. find the code in Kingston, compare to the later versions where it broke, replace the broken code with Kingston (working) code. Besides the fact that this was broken, what, 2-3 versions ago?

 
Based on the thread SquireBum referenced, this is not the only anomaly. So I suspect that fixing "just this one thing" would require extensive QA to see how it impacts whatever that code "touches," which includes MIDI, automation, audio, tempo changes, etc. etc. Something happened in an update to break it because code doesn't break itself; so fixing the "break" also means dealing with whatever was added - very possibly to fix a different bug - that caused the break. Better to jettison the code and clean it up once and for all. Also there are workarounds, as mentioned in the referenced thread; while kludges are never wonderful, there's less incentive to fix something that's conditionally functional compared to something that doesn't work at all or causes crashes.
 

Apologies for venting to you Craig, but you're representing Cakewalk at this point. If I neglected my clients in this manner (5-6 months and counting), I'd have no clients.

 
If I did really represent Cakewalk, I would say that specifying proper ripple editing as a high-priority fix shows that the needs of clients aren't being ignored, but that the company prefers implementing a long-term permanent solution over a band-aid that may result in further problems.
 
As a user, which I definitely do represent , I have confirmed this bug exists, but I'd rather keep doing workarounds short-term while they figure out a long-term solution instead of having a short-term solution that delays a long-term solution. But that's just one person's opinion and I'm sure it's not the only valid one.