Ripple editing behavior changes

[dangguidan]

Open global ripple editing and move items under the folder. If there is an envelope point in the folder track after the item, it will move along with the item (this is possible for versions before 7.27)
7.28 and 7.29 are not allowed.
V7.27:

V7.30:

[schwa]

This was a bugfix in 7.28:

Ripple: fix ripple-all potentially affecting automation too early on non-edited tracks

Here are a couple of forum threads reporting the previous behavior as a bug (there are other such reports):

https://forum.cockos.com/showthread.php?t=252027
https://forum.cockos.com/showthread.php?t=265797

An .rpp demonstrating the issue is attached, and screencap. The automation under the note "this automation should not move" would move in 7.27 and earlier. You are saying that you expect that automation to move. On balance I think the current behavior is more likely to be expected.

I think you will get the behavior you want if you enclose the media item in a razor edit (alt+right drag, or run the action "Razor edit: Enclose media items") and then move the razor edit with ripple-all-tracks enabled.

[dangguidan]

Understood, thank you!

[benmiller]

Originally Posted by schwa

This was a bugfix in 7.28:



Here are a couple of forum threads reporting the previous behavior as a bug (there are other such reports):

In the the posts you linked which report the old behaviour as a bug, and in your gif, the automation points which shouldn't move are directly under an item. and so their timing is directly related to that item, so it makes sense that they shouldn't move.

But in my example here
https://forum.cockos.com/showpost.ph...7&postcount=13
and in dangguidan's post above the automation points are not under an item in that track, so i believe it make sense for them to move. It seems both behaviors should be compatible.

but there are probably situation where one could want the automation points which aren't under an item to stay where they are....

yet an other ripple edit option? "ripple edit affects automation point which aren't under an item which isn't moving"

[schwa]

If "move envelope points with media items" is disabled, then no envelope points move when editing media items, regardless of whether ripple editing is enabled.

So, when "move envelope points with media items" is enabled, I think it makes sense that only envelope points under media items move when editing media items. If ripple editing is enabled, then envelope points to the right of the media items should also move.

As mentioned above, using a razor edit instead of a media item edit causes all envelope points in the project to obey ripple, which I also think makes sense, because that behavior doesn't depend on the "move envelope points with media items" setting.

[Meo-Ada Mespotine]

I understand the changes, however, I would prefer an option for the old ripple behavior, so it's possible to have it behave as some of us are used to.

[DerTonmeister]

I stumbled over this today. I was used to do it before and it was a pain not to have it. In a 100 track project I don‘t think razor edit is a valid option when editing a live performance. It just takes way to long to set the razor edit area every single time. Ripple is just touch and move.
In which scenario you‘d want to move all items and envelopes and just leave those on folder tracks where they were?
I think you should just rename "move envelope points with media items" to „move envelope points when ripple editing“

[RobinGShore]

I just discovered this change the hard way as well. I understand the issue that was trying to be addressed, but I feel like the "bug fix" did just as much harm as good.

Originally Posted by schwa

On balance I think the current behavior is more likely to be expected.

I'm not sure I agree with that. The current behavior can completely bork your mix if you have any automation on a VCA track, a folder parent, an fx bus, or a sub-master.

The current behavior could be expected in the specific situation where an item begins before the edit, but ends after it and said item has track automation overlapping it after the edit. In all other situations though, if both ripple all and move envelope points are enabled, the expectation is that all automation downstream of the edit will move, whether or not the automation is on a track that contains items that start after the edit. This is how it always worked up until recently, and it's the behavior that I (and I assume at least some others) have come to rely on to be able to edit quickly.

I use ripple-all editing constantly when editing podcasts,and audio drama projects and this new behavior effectively destroys a big part of my workflow, and slows the whole process down exponentially. Now every time I make an edit I have to worry about readjusting a bunch of automation data across a whole slew of different envelopes.

As mentioned above, using a razor edit instead of a media item edit causes all envelope points in the project to obey ripple, which I also think makes sense

I guess this kind of makes sense in theory, but it feels like a workaround, and in practice it's gonna be tough to erase 10+ years of intuitive muscle memory telling me to just grab an item and move it, rather than enclosing it in a razor edit first. There are also some situations where razor edits don't really work. For example, nudging doesn't work with razor edits, and there are no razor edit equivalents for the actions to move items left/right, or move items to edit cursor, so there's no good I'm also not able to use the new feature of rippling when editing item edges if I use razor edits.

[RobinGShore]

Originally Posted by schwa

This was a bugfix in 7.28:

An .rpp demonstrating the issue is attached, and screencap...

Here's a modified version of that screencap showing the problem with the current behavior.




The automated fade affecting the items in the folder track is completely ruined after the edit. Imagine that sort of thing times 1000 in a more complex project.

[Meo-Ada Mespotine]

This does not only affect folder-tracks, but regular tracks as well.

This is a huge problem for editing podcasts with Ultraschall, where people expect envelopes to behave the old way. This creates unexpected results when having a lot of automation written.

Imagine fx-plugins like vinyl-fx that shall fade in before the item starts, fade in done with automation. And you move the items around, as you want them to start later but the fade-in-automation of the fx doesn't move.
So you hit play and have the vinyl-fx fading in far too early...abruptly stopping, as the automation got cut off due the move and then restarting, when the moved item is reached by the playhead.

I'm not a fan and hope, you can make the new behavior optional.

I see all the support-work coming in for our Ultraschall team to explain all these people, how to use Razor-Edit instead of the Ripple-Edit behavior they are used to for 10 years of usage. A lot less experienced users simply will be too overwhelmed by it...

[akademie]

Definitely if I switch "Ripple" ON, then I am expecting that "EVERYTHING" moves in timeline, not just something (and strangely selective)!
That is unusable behavior for almost anything

[schwa]

Please see this post regarding this change and a potential additional change:

https://forum.cockos.com/showthread.php?t=297941