I would like to combine the Trim and Fill functions to offset the entire volume automation of an audio track via fader action, which - to my humble brain - seems like a quite handy and intuitive idea.
With Trim disabled, this works fine: after I adjust the fader, the automation track is set to the new level, according to the settings I have made. Great!
When Trim is enabled, setting the Fill functions “To Punch”, “To Start” and “To End” does nothing. Adjusting the fader always affects the entire automation from punch-in to the end of the track. The area between the start and punch-in points remains untouched. With “To Punch” it should equalize the level from punch-out back to punch-in. It should, but it doesn’t.
“To Loop” works perfectly. I have not tried “Gaps”.
Next, there’s a problem with “Auto-Latch” and “Cross-Over”. If I enable these while Trim is also enabled, the automation track goes crazy after I release the fader. It flickers back and forth between the old and new values, which is not only a GUI error, but is also audible.
What’s going on here? Have I discovered some nice features or am I allowed to use the B-word again?
I’m not 100% sure I follow your explanation. I’m assuming that one goal is to write one ‘flat line’ from beginning to end using fill set to “To Start” and “To End”. I agree, with Trim disabled that works.
I’m not seeing all of that.
Without “Preview” what happens to me is that with Touch/Trim and “To Start” and “To End” all enabled the system writes the trim-offset as long as the fader is touched, when releasing the fader it stops writing, and it only writes where the fader is touched. In other words it does not change automation to the end of the track. Perhaps I’m missing what your settings are (please post a picture).
But regardless of us seeing different things (I’m on v13 btw) it doesn’t function in a way that is intuitive (or correct in my opinion).
Not for me. If I have set fill to “Loop” and use Touch Trim then when I punch out of automation write the changes are only written where they happened, in other words the fill range is never offset as a whole.
As you can see above I started writing with touch trim and when I reached the end of that looped range it punched out as it should but the offset only occurred where it happened, so the loop is quite literally not filled with the automation event.
I don’t have that on my end.
I’ve complained plenty about the automation system and sadly it seems that Steinberg has decided that other things are more important and have simply put any fixes low on the priority list.
I made a report about “Trim” problems back in 2018 after another poster had a problem:
As you can see that was version 8… half a decade later now. And I think I also did repro steps in another thread for either the same problem or something very closely related.
I’ve basically given up on using Trim in certain ways because it never works in a logical way.
Maybe tag one of the people from Steinberg who participate in this section.