Page 1 of 1

DP11 bug: Countoff shifts track timing?!

Posted: Thu Aug 12, 2021 1:30 am
by larrytheo
Wow, this is a really weird one. I am running DP 11.0 on a Late 2013 Mac Pro under Mojave 10.14.6. I have a session running at 96 kHz/24-bit with about 17 tracks in it, about 19 plugins, and 3 VIs, so not a super-intense session. I set up to record a track, including enabling a countoff of 8 bars (I record alone and need time to get to the mic). In this particular song, the drums enter about four or five bars before the vocal I was to record, however, one of the drum tracks (stereo OH) entered nearly a second before all of the rest of the drums and other tracks. I confirmed that the soundbite in the OH track was properly placed in time, and after a good deal of troubleshooting finally identified the countoff as the culprit:

- the track only comes in early when Countoff is on and playback is started from the beginning of the session. If Countoff is off or playback is started after the start of the session, the OH track enters at the correct time.

- Only the OH track exhibits this behavior

- It happens in record or play.

- If the OH track enters early and I stop and then restart playback, the OH track is in time again.

- I created a new stereo track for OH and dragged the soundbite to it from the old track, then deleted the old track. The problem remained.

- The behavior as described above is completely repeatable and consistent.

Since I tried replacing the track, that suggests the track itself is not the problem. Theoretically, that might point the finger at the soundbite or audio file, but I can't see any way it could be the audio file if it sometimes plays exactly correctly in time.

Thoughts? Curative magic spells?

Re: DP11 bug: Countoff shifts track timing?!

Posted: Thu Aug 12, 2021 1:40 am
by HCMarkus
Weird. Have you tried merging the offending track? That could resolve the problem.

Re: DP11 bug: Countoff shifts track timing?!

Posted: Thu Aug 12, 2021 1:45 am
by larrytheo
Merging it with what? You mean merging all of the soundbites on the track? I could try that. There's only about four edits on the whole track, and they are near the end of the song.

Re: DP11 bug: Countoff shifts track timing?!

Posted: Thu Aug 12, 2021 1:50 am
by larrytheo
OK, I merged all the soundbites on the track. Still coming in early when countoff is enabled.

Re: DP11 bug: Countoff shifts track timing?!

Posted: Thu Aug 12, 2021 2:08 am
by HCMarkus
I had high hopes that might work.

Sounds like you should not start at the beginning. If your tracks stat right from the top if the sequence, consider shifting everything back by a couple of bars and using the two beginning bars for countoff. That's the way I always set up projects, so DP's countoff is never needed.

This may be related to viewtopic.php?f=1&t=69065

Re: DP11 bug: Countoff shifts track timing?!

Posted: Thu Aug 12, 2021 1:56 pm
by larrytheo
If I'm just going to give up on fixing it and find a workaround, it's even simpler than that: I can just mute the OH track while I'm overdubbing. But I'd rather either find a fix or report it officially as a bug.

Re: DP11 bug: Countoff shifts track timing?!

Posted: Sat Aug 14, 2021 6:11 am
by greg328
Does the offending overhead track have blank audio leader from the very beginning of the project? Or does the soundbite begin after bar one? If no blank leader, try creating that, then merging everything in the track into one long audio file, if it’s not already.

This may improve playback/record timing


Sent from my iPhone using Tapatalk

Re: DP11 bug: Countoff shifts track timing?!

Posted: Sat Aug 14, 2021 2:53 pm
by larrytheo
The file starts at the beginning of the session. (The tracks were originally recorded to 2-inch 16-track tape, then laid back in a single continuous pass per reel to Pro Tools at 192 kHz/24-bit, then the files imported to a DP session, so all files start at the beginning of the session.) I think I trimmed the soundbite to where the drums actually enter (I'm working on another song at the moment.) Next time I open that file, I'll try extending the soundbite back to the beginning of the session and see if that helps. Of course, even if it does, that's certainly a bug, but at least the would help in isolating it.

I ended up working around it by muting the OH track while overdubbing, but I'd still like to figure out what's going on in case the issue recurs.