[fetidus]

Originally Posted by EricTbone

Sorry, you didn't say that so I had no idea that's what you meant.

However, the question remains. Why wouldn't want that to move? What real world scenario would result in you wanting to ripple edit your entire project, rearranging audio data across all tracks along with its automation data, but have one piece of audio that should not move with respect to everything else?

My example is a real world scenario, what I have to imagine is by far the most common case.



You appear to be taking this as antagonism, but I'm honestly just trying to understand that. As I said, I can't think of a scenario where you'd want that default behavior. Your answer, if you think about it, has simply been to say "but imagine I wanted that behavior? Then I'd want it." I'm trying to understand why you'd want that behavior. What real world ripped editing workflow would result in you wanting to move automation data independent of the audio it's affecting?

Not taking it as antagonism at all, apologies if it comes across that way. This is just an intelligent discussion about a feature.

As for having no idea that's what I meant -- I had posted the GIF so I thought it would show enough detail with the folder, etc... and again, apologies for not being more detailed in my description before. I hope it's more clear now.

Like I mentioned, there are definitely scenarios where this current behavior is fine and valuable as-is -- I showed one already. It's more common with my projects than perhaps other people, but I tend to nest folders/buses, and buses can contain items/takes as well. I use that for alignment (really great for lining up transients), I might have a video clip or other reference track in there that I don't want to move, which could prove *disastrous* if I accidentally move the whole track, knocking my project out of alignment, and yet I still want to move the automation in the track. So it's working great as-is. Or perhaps I might have *accidentally* moved something into that folder/bus parent track and then that would then force the automation data NOT to move if the default behavior was as you want. And so forth with VCA too, etc. I can probably come up with grouping examples, automation item examples, etc...

And again, I stress that the automation data is NOT attached specifically to an item or take... technically it is attached to the TRACK. So as track data, it is independent of the items/takes. It just so happens that quite a bit of our workflows assume they are integrally related, so it has a nice default behavior when you move an item, the automation underneath moves. But that's still not fully the item's automation, even if we perceive it as such. When you ripple, the demarcation point is absolute at the beginning of the selected item, and ALL TRACK ripple mode does *exactly* that -- it ripples ALL TRACK data... and thus all data flows from that initial point. It's track data, not item or take data, so it should ripple. And it's logical that way, at least to me, and it's been the default behavior for many years. You guys seem to be very focused on the idea that the automation data belongs exclusively to the item/take. But again, it's track data.

Sure, your scenario make sense as well, and that's why I would be really happy to have the option you are talking about. You guys can set up your Reaper to have that as your default option, and you'll be happy. I can keep the old behavior and I'll be happy. If I want to switch modes, I'll go trigger your mode. There's really nothing lost here. I'm not misunderstanding what you want, why you want it, or its worth. I'm just disagreeing that it should replace the current behavior or be default behavior (unless you select it in your settings to be your personal default).