automation doesn't follow fade dragging

[kosmokrator]

@Avid:
It's really upsetting that this bug is still around after what - more than 2 years now?

Especially with Atmos mixing this is just such a showstopper.

What's the reason this doesn't make the list of bugs being addressed?

[nednednerb]

That doesn't sound like a bug..... What does an automation of an insert or send level have to do with clip edges? Sure, maybe a feature request.. "IF there is one or more breakpoint on a fade edge, MOVE breakpoint(s) with any edits on edges."

Otherwise, I could move fade edges and move breakpoints all day long and I never thought it was a bug. It seems natural to not accidentally move clips and then find breakpoints all over the wrong place. That's what I mean by "feature request" and by saying I don't experience this as a bug. If it was an option to turn on and off at whim, and THEN it wasn't working, I would call that a bug.

For now, I want my breakpoints to stay where I put them, so thanks, Avid! (Sincerely).

[marsian]

ned,

you may have noted that it IS a feature already.
But it acts buggy when "automation follows edit" is switched on. As kosmokrator mentioned.
It's a real bummer when mixing and writing automation in preview.


Best
Maik

[smurfyou]

Yes ned I think you misunderstand. It is an existing feature that stopped working correctly ages ago. Is completely necessary in post.

[nednednerb]

What happens to breakpoints behind the fade you drag passed? What happens to them, do they auto delete? Does automation spike back up after the breakpoint at fade end gets moved "with edit"?

For me, if I copy and paste a clip, automation moves just fine. The "edge case" of moving the edges seems to me like one of a programming choice, and one where the behaviour as described makes me question as above.

AT LEAST, this seems to be an adaptation or interpretation of Automation Follows Edit, where there could be a potential issue like the breakpoint now after the clip making automation unintended, after the breakpoint on the fade gets moved with the fade drag.

If you don't understand this possibility, maybe the bug isn't well expressed and I don't get it. Seems to do what I would expect now. Maybe there was a way or could be a way to deal with that, maybe they decided it wasn't the best idea sometimes, but didn't go back on the feature? And that's why I express that they chose one option, you want the other as default. I can totally accept both as desirable. There are always issues, and I'd rather have both than call what's now a bug, because I'd have to call both buggy from the other intended functionality.

[kosmokrator]

Originally Posted by nednednerb

I don't get it..

This sums it up.
It’s a well-documented bug that is a complete PITA in Post Production mixing.
If you don’t understand the issue, that’s fine, it means you don’t have a problem with it.
There are other threads on the DUC explaining it. Go there to see what we’re talking about.
But please stop diluting my thread.
It was a question to Avid.

Thanks.

[Farhoof]

This has been around since PT 2019.10 so more than 3 years (!)

It has killed my workflow for post and has introduced a LOT of issues in the beginning. To clarify for people, when automation is written to the exact length of a clip, e.g. panning for ambiences, the automation would stick to the clip edges when you moved the fade out/in when extending the clip for another scene at the same location (generally location ambiences are copy/pasted and then adjusted to length and taste). Panning would stay intact. All other edge-to-edge automation stays intact. It has worked this way since forever. Now it does not. This can mess up your workflow a lot and sometimes will not be noticed right away. The workaround is to not use the hand tool to move the fade, but to use the trim tool to extend the clip itself. That way the automation moves along as intended, but that's like 20 years of muscle memory you have to ignore. And you can't move 8 tracks at once, only per track.

It is already marked as a bug, Avid is aware. There is no fix coming as it's not a big deal for most people. We have to hope it might be fixed by mistake just as it broke by mistake.

[nednednerb]

I'm free to ask questions. Avid Support is where you can ask Avid. They aren't obligated to answer here, so you might be blamed for diluting the forum. I also have free speech, go figure. So I am not complaining about your post. Just pointing out I can speak on any thread.

Again, how does my question get resolved? I still think it's a design choice that might deserve alternate settings rather than being simply called a bug. It requires thought on side of developers how to deal with my question as well as your intended function.

Especially, here is the clincher, above some are speaking about "most people" not being bothered. Are most people like me, thinking there is no bug here?

Again, I agree you deserve an option for your workflow, but I apologize profusely for asking questions that seemed reasonable to me. Lol, just a bit of snark there/

[kosmokrator]

Originally Posted by Farhoof

This has been around since PT 2019.10 so more than 3 years (!)

It has killed my workflow for post and has introduced a LOT of issues in the beginning. To clarify for people, when automation is written to the exact length of a clip, e.g. panning for ambiences, the automation would stick to the clip edges when you moved the fade out/in when extending the clip for another scene at the same location (generally location ambiences are copy/pasted and then adjusted to length and taste). Panning would stay intact. All other edge-to-edge automation stays intact. It has worked this way since forever. Now it does not. This can mess up your workflow a lot and sometimes will not be noticed right away. The workaround is to not use the hand tool to move the fade, but to use the trim tool to extend the clip itself. That way the automation moves along as intended, but that's like 20 years of muscle memory you have to ignore. And you can't move 8 tracks at once, only per track.

It is already marked as a bug, Avid is aware. There is no fix coming as it's not a big deal for most people. We have to hope it might be fixed by mistake just as it broke by mistake.

Well, what's really annoying to me is that while this bug might not be a major issue for most people in music, it certainly is a major issue for the people who have made the biggest investment into the Avid ecosystem, which would be post houses.

After spending a not small 6-figure amount on Avid systems including multiple S6 units, I'd certainly hope that top priority bugs would be addressed or at least an ETA be communicated.

And there are companies for whom this is as annoying who spent quite a bit more.

[Farhoof]

Originally Posted by nednednerb

<snip>
Especially, here is the clincher, above some are speaking about "most people" not being bothered. Are most people like me, thinking there is no bug here?

Most people don't use a clip based workflow like we do in post. Music is generally a track based workflow. Also not everybody will notice this issue, when your panning or eq jumps to a default setting on a single track when you have like 20+ (audible) tracks going you might not notice it. I assume most people aren't bothered by it since there are way too few posts about this. There have been similar issues like this fixed within weeks via a dotfix. This specific bug is being ignored and us powerusers don't know why.

There is no speculation about whether this is a bug or not, it is already confirmed as a bug. It's just not being fixed.