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.

Anderton

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.

Sonar would just have to do whatever is necessary to preserve the structure of the song after the deleted time. If that involves moving a time sig event to the start of the "after" section then so be it.

So let's say you have 12 measures, starting at 4/4. You want to cut 5-8 but there is a change to 6/8 at measure 7. Sonar would cut measures 5/8, moving the sig change to the new measure 5.

I think the salient point here is that the Bakers would have to think what would be required of the end user to do this manually, and automate it intelligently. Way within their ability, of course.

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

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.

But then you have to wonder, if you're deleting time from a song that was synced to video, the whole thing is then going to be out of sync with the video after the cut anyway. Sonar isn't a video editing program, it's an audio editing program. So whatever changes the user has to make to the video to resync it after a time deletion is really up to them. It's far more important that Sonar preserve time signature and tempo changes, given that it's a music creation program.

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.

There is of course, another possibility, which is that a Delete Time function would only be possible on regions that were empty of data. Therefore it's the user's responsibility to tidy up any "loose ends" before Sonar plugs the gap intelligently.

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?

sharke
So to recap, a "delete time" function should:
 
1) Delete ALL data in the area you specify
2) Move ALL data to the left to fill the gap. 
 

3) Move ALL bus automation left to fill the gap. 
 

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.

sharke
But then you have to wonder, if you're deleting time from a song that was synced to video, the whole thing is then going to be out of sync with the video after the cut anyway.

Not necessarily. It may not be a 1:1 sync issue, like sound effects, but a music bed where you decide to delete a repeat of a verse, and extend the end. You don't necessarily care what's speeding up, just that something is speeding up at that time. I encounter this situation often.