Henrik Ekblom wrote:

I have checked with some co-workers regarding this issue, and it’s strange thing, since the latency handling is done by DP.

Do you have the MIDI on the Superior Drummer 3 song track, or in a MIDI track in DP? Is there a difference if you try the one that you don’t have?

Thanks for the reply.

I don’t use the SD3 song track. All MIDI is in DP. I haven’t had a chance to try the song track (but it shouldn’t matter, right? External MIDI is “allowed,” and again, this doesn’t happen with EZD2—even with external MIDI). That said, I posted this issue in a DP forum, and received the following replies from another power user:

“Since I’m a big fan of SD3, I tried this, and I can confirm this bug, exactly as you describe it. Three things:

• For the bug to occur, the master fader needs to be assigned to the same output as the tracks to which you are recording the SD3 splits. I.e., if those audio split tracks are assigned to Out 1-2, and your master is assigned to Out 3-4, the bug doesn’t happen. (Obviously that would be a very unusual situation, but figured I’d try it just for more data). [snip]

• If you assign the multi outs from SD3 to aux tracks (I frequently do this with various VI’s), the sync bug doesn’t occur—even with a heavy plug-in on the master fader, the audio plays in sync. It’s only when recording audio files that it happens.

Good catch!”

And his follow-up:

“AND… one more piece of data. I tried this exact test using Pro Tools—PT does <u class=””>not</u> exhibit this behavior; it records from SD3’s multi outs to PT audio tracks via internal bussing just fine, even with a heavy plug-in on the master fader. So this may not simply be a Toontrack issue, or if it is, it’s one that impacts DP but not PT (I’m using the latest versions of SD3, DP and PT Ultimate). Strange…”

Does this info help? Are you able to communicate with MOTU about this issue?

Olof Westman wrote:

The thing is that latency compensation is something a host does, not a plug-in. So – if there is a bug in the latency compensation then that bug would sit in the host.

Could it be this issue(not a bug) in DP?

http://www.motunation.com/forum/viewtopic.php?f=1&t=63021&start=0

http://www.motunation.com/forum/viewtopic.php?f=1&t=60255

I understand what you’re saying, but no, it’s neither of the above-linked issues. My MIDI is carefully quantized and is properly aligned to the grid. This has nothing to do with the buffers. I’m very, very familiar with all of those features. (I’ve been a MOTU beta-tester for 0ver 20 years, and I know DP very, very well.) I’m not saying DP is bug-free. Of course not. But this does not seem to be a DP bug. Or, put differently, there’s something odd about the way SD3 is interacting with DP.

Remember:

This project has over a dozen VIs—all of which are performing perfectly, with the exception of SD3. Numerous instances of Kontakt? Printed perfectly. Ivory, Stylus RMX, Trilian, Omnisphere—all print perfectly. EZDrummer 2 prints perfectly. The only VI that does not play nicely, under these circumstances, is SD3. So, how could that be DP’s fault? Why would DP “decide” to treat SD3 differently than it treats every other VI in the project?

Also, did you read the reply from the other DP user that I posted above? He corroborated my observations with great detail.

Why would DP print every VI perfectly with the exception of SD3, unless there’s something about SD3 that’s causing DP to do that?

Olof Westman wrote:

Well, then there is a bug in DP. You have to talk to them about it.

To be clear, upon what evidence are you basing that conclusion?

When a dozen other VIs behave as expected, and SD3 is the only one that misbehaves, how does that lead you to conclude that it’s the fault of the host? That appears to defy all logic.

(BTW, the tester above just confirmed that his MIDI was in the song track. So, there’s that.)

Thanks.