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.

+1 > I would imagine most people would just assume that a professional DAW could do that anyway.
 
I see no difficulty in keeping the length of MIDI notes. If they extend beyond the point of the cut, so be it.
 
And if not, then the user can extend the clip again to the length of the MIDI note (as is the case now).
Audio clips, too, by the way. They retain their underlying audio file and can be extended to the desired length (unless they have been bounced).

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.

By coincidence, I spent an hour earlier this morning helping my son sort out a mess resulting from inserting four bars into the middle of a project with tempo map changes and automation.
 
I fear my attitude about this kind of thing is becoming less patient and more uncompromising. I don't care whether or not fixing these things can be given a good marketing spin. I don't even care if the coding is difficult. These are basic DAW functions. Having a way to easily get the desired result is essential to a DAW product.
 
I'm not one of these "SONAR sux!" trolls. At the risk of sounding corny, Cakewalk and SONAR have been part of my life for twenty five years. I'm fond of the product; I'm pulling for it. I'm happy with the changes that Gibson has apparently encouraged (or at least allowed), not least the contributions of the excellent Craig Anderton. But that doesn't stop me from saying that there are some long standing issues (already highlighted by others, better than I could) that really need attention soon.

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?

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.

A quick try in a "competing DAW" reveals they haven't thought it through, really. The feature exists, but it summarily removes any tempo and time signature changes, too.

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.

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. 
 

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.

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.

 
Correct. But a tempo change is a single event. If you remove it, then the tempo is whatever the tempo was prior to that tempo change, until the next tempo change occurs. So you're still left with SONAR not knowing what the "correct" thing is to do with that tempo change.