Delete Hole

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

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.

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

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...

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.