[Bug] Trim or Nudge Destroying Trailing Auto Breakpoints Written using Write-To

[jeremiahmoore]

This is similar to, but distinct from, the bug Frank posted. The behavior he's describing seems to happen INSIDE the region tail, this is TRAILING the region. (frank's flickr link, my flickr link) I suspect it's related.

I write a lot of automation using Write To Enabled. Typically looping a section in Preview to set EQ or other plug-ins, then stamping with "write to all." Sometimes later I perform some edits on that material, for instance untrimming some roomtone tails to smooth transitions. Opening up the tail of a region written this way wipes out the trailing breakpoint, creating a ramp in every automated parameter until the next breakpoint. Which could mean creating an EQ ramp over the next five minutes of audio. This can be VERY ugly, esp when it's not discovered until later becuase you weren't viewing automation when the nudge/untrimming was done.

I consider this a "data loss" bug, as areas downstream in the timeline from where you're working are affected. I first discovered it because a whole section of a film I was working on suddenly had the wrong EQ applied.

Workaround: Print automation ahead and behind the region boundaries. (best to print ahead of anyway, due to lag)


To reproduce:

1)Set Up
- new audio track
- put some audio on the track, and trim it (select middle, cmd-T)
- view volume automation
- pin the automation by placing some breakpoints before the head and after the tail of the audio

2)Write Automation with Write-To
- transport in stop, and volume automation write-enabled
- select the region (double-click w/ trim tool for instance)
- move the fader on the track to a new value (as would occur using Preview)
- write that value to the region using "write to current" (cmd-/)

3)Untrim the tail
- switch track view to Waveform
- with trim tool, open the tail of the audio a bit, or nudge it right
- switch back to Volume Automation view.

Now you've got an unintended ramp from the value written on the region to the next breakpoint.
This affects ALL automation not just volume.


The behavior SHOULD be to slide the breakpoint to the rear. As in:

2b)Do all the above, replacing (2) with the following:
- select the region (double-click w/ trim tool for instance)
- use the trim tool to write automation.

This is how un-trimming the tail SHOULD affect the automation.

More info:
on looking closely, I discovered that "write to" places the trailing breakpoint one sample AFTER the region tail; Trim placed it one sample WITHIN the region tail. See:
http://www.flickr.com/photos/jaiapeo...7604485379718/


config:
PT7.4cs7
PT8: I tried this on PT8 at AES, and it was there.
HD2 Accel PCIe
MacOS 10.4.11 powerPC
Plug-ins from Digidesign, McDSP, Waves, GRM, Audio Ease, SoundToys, WaveArts, iZotope


-jeremiah

[Frank Kruse]

I can not count the hours (or days) I´ve spent this year fixing things like the above.


Jeremiah, good catch!

frank.

[DigiTechSupt]

We are aware of this issue, definitely, and have it logged for a fix. When that may happen, I'm not sure. I prod them regularly to get these kinds of things to the top of the queue as they really are workflow killers.

[jeremiahmoore]

Thanks Digi, glad to hear it's in the works.

For some working styles (using a lot of automation write-to, as many of us in post do) this bug can create a minefield, in which much careful work can be disturbed or destroyed. Therefore I believe it should be a priority.

-jeremiah

Originally Posted by DigiTechSupt

We are aware of this issue, definitely, and have it logged for a fix. When that may happen, I'm not sure. I prod them regularly to get these kinds of things to the top of the queue as they really are workflow killers.