Have you submitted a support ticket using the example you used here? I would suggest doing that if you haven't already...

sharke
[...] It's not a glamorous feature to tout [...]

I disagree with this, since I feel this is the foundation required for elegant arrangement. Being able to chop and drag "chunks" all over a project without concerns for markers/automation/takes/etc. would make sandboxing go at lightning speed and not distract the user from composition. If it is a "completely vertical" section, markers, tempos, and automations should all go with it, and snap to sections they but up against. From the same reasoning, being able to hit Ctrl-A and drag that vertical section would allow the entire project to be slid left/right (or even grab the timeline and just move it - keeping all else "relative"). As alluded to, most video software has these features baked in (ripple delete, clip snapping, etc.) solely because people hate to watch "black screens" during a video.
 
As Craig mentioned, I too sandbox audio (even for what will eventually become MIDI parts) only because I can drag/drop those all over without little worry. When a "what just happened" snags me, I am often done for the night.

mettelus

sharke
[...] It's not a glamorous feature to tout [...]

I disagree with this, since I feel this is the foundation required for elegant arrangement. Being able to chop and drag "chunks" all over a project without concerns for markers/automation/takes/etc. would make sandboxing go at lightning speed and not distract the user from composition. If it is a "completely vertical" section, markers, tempos, and automations should all go with it, and snap to sections they but up against. From the same reasoning, being able to hit Ctrl-A and drag that vertical section would allow the entire project to be slid left/right (or even grab the timeline and just move it - keeping all else "relative"). As alluded to, most video software has these features baked in (ripple delete, clip snapping, etc.) solely because people hate to watch "black screens" during a video.
 
As Craig mentioned, I too sandbox audio (even for what will eventually become MIDI parts) only because I can drag/drop those all over without little worry. When a "what just happened" snags me, I am often done for the night.

What I meant by it not being a glamorous feature to market was, I would imagine most people would just assume that a professional DAW could do that anyway. Frankly like most people I was shocked that it didn't, but muddled along anyway.

Anderton
I'd like to propose my workflow to Cakewalk, but would be interested if anyone has improvements to the suggested workflow before I do.
 
The one thing I would want to avoid is getting bogged down with something like "Well, we really need check boxes for what we want to remove," or "it should automatically move any time signature it finds to the beginning of the hole," etc. I think of the odds of implementation are greatest if a really simple change covers 90% of what people need, as opposed to a complex change covering what 95% of what people want.

Well for starters, if it didn't deal with time signatures or tempo changes correctly, I would still consider it a broken feature. Might as well do it properly. If you move clips without moving time signature changes then you've essentially broken the song.

I think the only check boxes required would be to ask the user what they want Sonar to do with any overlapping data. If any data straddles the hole boundaries then it could be trimmed backwards or forwards as required. I think it's otherwise a very simple operation in which a section of the entire project is deleted and the gap is closed, preserving everything else in the project INCLUDING the time ruler and its signature and tempo changes.

Anderton

sharke
What I meant by it not being a glamorous feature to market was...

It may not be glamorous, but a big part of what Cakewalk is doing these days involves optimizations and other improvements. While these may not matter to new users, as the response in this forum indicates, it's very important to existing users and that is part of marketing...the more an existing user likes SONAR, the more they'll talk about it and the happier they'll feel about using the program.
 
I just hope that something like this could be implemented easily, without having to rip the program apart and put it back together again as that is always a candidate for the Law of Unintended Consequences.

Yeah I imagine it's not a trivial operation at the code level. Maybe that's why Cakewalk have avoided doing it. However it should be a trivial operation at the user level. That's what coders do, they transfer heavy lifting from the user to the code.

sharke

Anderton
I'd like to propose my workflow to Cakewalk, but would be interested if anyone has improvements to the suggested workflow before I do.
 
The one thing I would want to avoid is getting bogged down with something like "Well, we really need check boxes for what we want to remove," or "it should automatically move any time signature it finds to the beginning of the hole," etc. I think of the odds of implementation are greatest if a really simple change covers 90% of what people need, as opposed to a complex change covering what 95% of what people want.

Well for starters, if it didn't deal with time signatures or tempo changes correctly, I would still consider it a broken feature. Might as well do it properly. If you move clips without moving time signature changes then you've essentially broken the song.

How do you define "correctly"? Suppose you have 12 measures. You want to delete measures 5-8. A tempo change occurs at the beginning of measure 7. How is SONAR supposed to know where to put something you want to delete?

It could produce a pop-up menu in that situation.
 
"Tempo changes were detected in the area to be deleted. Do you want to:

1. Remove tempo changes entirely (data following the cut will take on the tempo of the data preceding the cut)
2. Coalesce tempo changes (data following the cut will take on the tempo of the final tempo change in the area to be deleted)"

Usually you want option 2, but in a MIDI-only situation I can imagine a use for option 1.

Paul P

Anderton
How do you define "correctly"? Suppose you have 12 measures. You want to delete measures 5-8. A tempo change occurs at the beginning of measure 7. How is SONAR supposed to know where to put something you want to delete?

In this case you aren't deleting the tempo change, only the part of the song that contains it.  A tempo change is an event that affects what follows until another one is encountered.  Whatever followed the delete is still at that tempo so Sonar just has to move the last tempo change within the delete forward (or back).
 
I haven't seen the code, but I can imagine it, and I really don't see that it could be that difficult, unless it's 20 year old spaghetti that no one wants to touch. 
 

I agree, all Sonar has to do is think of each measure as an entity in its own right. In effect, the tempo change in this case would be moved intelligently, to measure 5 of the edited song. Each successive measure should retain its original time signature.

sharke
I agree, all Sonar has to do is think of each measure as an entity in its own right. In effect, the tempo change in this case would be moved intelligently, to measure 5 of the edited song. Each successive measure should retain its original time signature.

It's not that simple. Maybe you wanted the tempo change to be at measure 7 because you're fitting to time with video, so putting it at 5 would screw things up. Or maybe the clips that traversed measure 7 lent themselves well to a tempo change, which was necessary to set the stage to subsequent measures would sound good. Now you're expecting those measures to still sound good without the transition. So maybe you want the transition to still occur at measure 7.
 
As I said, I'd rather have something that's implementable and takes care of what 90% of the people need...the other 5% can re-insert the tempo change where they want it to go. But based on what I hear on the radio, tempo changes seem to have fallen out of favor so I'm not sure how many people would be affected by tempo change issues.

Kylotan
It could produce a pop-up menu in that situation.
 
"Tempo changes were detected in the area to be deleted. Do you want to:

1. Remove tempo changes entirely (data following the cut will take on the tempo of the data preceding the cut)
2. Coalesce tempo changes (data following the cut will take on the tempo of the final tempo change in the area to be deleted)"

Usually you want option 2, but in a MIDI-only situation I can imagine a use for option 1.

Hmmm...with the workflow I suggested, option 1 would happen automatically if you removed a tempo change. I can see where option 2 might be what some people would want, but there would also need to be a third option, where the tempo change stays put (with audio for video, this is essential).
 
But, then this goes down a slippery slope with pop-ups saying a MIDI program change was detected, or a groove clip marker, or position-locked clips were detected...or a pitch bend was detected that didn't return to zero before the end of the region to be cut...accommodating all the various "corner cases" could get very complex, very fast. 
 
This is why I think a "delete it all, and if there's stuff you have to preserve, move it manually before deleting" is (hopefully) a simple enough solution that it could implemented easily, and solve the vast majority of issues people have.

Anderton

Kylotan
It could produce a pop-up menu in that situation.
 
"Tempo changes were detected in the area to be deleted. Do you want to:

1. Remove tempo changes entirely (data following the cut will take on the tempo of the data preceding the cut)
2. Coalesce tempo changes (data following the cut will take on the tempo of the final tempo change in the area to be deleted)"

Usually you want option 2, but in a MIDI-only situation I can imagine a use for option 1.

Hmmm...with the workflow I suggested, option 1 would happen automatically if you removed a tempo change. I can see where option 2 might be what some people would want, but there would also need to be a third option, where the tempo change stays put (with audio for video, this is essential).
 
But, then this goes down a slippery slope with pop-ups saying a MIDI program change was detected, or a groove clip marker, or position-locked clips were detected...or a pitch bend was detected that didn't return to zero before the end of the region to be cut...accommodating all the various "corner cases" could get very complex, very fast. 
 
This is why I think a "delete it all, and if there's stuff you have to preserve, move it manually before deleting" is (hopefully) a simple enough solution that it could implemented easily, and solve the vast majority of issues people have.

But Sonar already has options like insert time and delete hole which have options for things like markers, tempo changes etc - it's just that they don't work properly.

Moving time signature changes and tempo changes manually is a pain. What we're really looking for is a way to edit arrangements quickly and intuitively.

I record several shows each year, and post, I have to chop them up into separate multitrack song/projects.  I split all the tracks at the song boundaries, delete on either side, apply trimming, then I use the Slide function to slam everything that's left to the first measure (like Slide -10,000 measures).  Works every time.
 
Is Slide what you are looking for?

sonar is just too beautiful of a DAW to switch...although I think we're also about ready for the program to be a different GD color!  :D  I've tried Pro tools because so many people use it, it's just no contest, sonar wins there.