More on latency/triggering issue

Mikey MTC · Post by **Mikey MTC** » Sat Apr 26, 2008 11:48 pm

I saw a previous similar question to this from a few weeks ago but I'm not sure if this is the exact same thing.

Basically, I'm getting inconsistent performance with triggering, making Drumagog unusable.

I'll spell out what I'm doing. Keep in mind this is with a brand new 8 core Mac Pro with 6 gig of RAM, so I'm powered up pretty good now. This is with a large Pro Tools HD system.

(1) I'm choosing fixed latency mode, presuming this to offer the best triggering quality. I'm using the Steven Slate library.
(2) I note that the latency reported to Pro Tools is greater than that which can be compensated for (high 4,000'ish samples), so I disable any delay compensation for that track and manually nudge the track back by the exact amount.
(3) I've got an existing snare on one track and then another snare track triggering Drumagog, and they start off together but every now and then you hear a flam. When I go back to the offending hits they play in time again, so it's random and not actually any specific hit that's at fault.

NOTE: In the session in question, I think things were going fine with the snare track UNTIL I also did the same thing with the kick. As soon as I added this second Drumagog is when I think it went a bit weird - and it went weird for both of them.

I would have thought erratic performance like this would be a CPU problem, especially when it came on with the second instance, but we know an 8 core Mac Pro wouldn't even feel this ... UNLESS it's not setup properly. Like the CPU popup in the prefs which is currently set to 8 even though Pro Tools apparently cannot address 8 cores. Should this be set to 4? Any other setup tip that might be causing this? Is it a problem with Leopard which we're forced to use on these latest Macs?

Thanks.

Dizzi45Z · Post by **Dizzi45Z** » Mon Apr 28, 2008 11:35 pm

I have some similar questions as yours. I am both newer with Pro Tools HD and Drumagog and I have found it easier to trigger samples not using the fixed latency versions. Everything has seemed to line up better that way for me. However, I am curious what most Pro Tools HD users are doing to get their samples to line up the best.

Mikey MTC · Post by **Mikey MTC** » Mon Apr 28, 2008 11:50 pm

I've since gone back to this session and things have behaved a bit better. I tried a different approach.

Drumagog was claiming 80ms latency on the plugin itself so I nudged my Drumagog track earlier by that amount. Then I switched over into sample mode and nudged back to the right again the total system latency as reported by Pro Tools (it was only in the hundreds of samples) depending on what other plugs I had in there. I didn't think this last step should have been necessary but everything synced up fine after that.

My flams weren't happening this time, though I don't know if there's any link between these two. Who knows!

It would be good if Rim or Teri could chime in with an explanation of the "ultimate" recommended Pro Tools workflow, given a powerful Mac Pro computer.

Thanks.

Teri · Post by **Teri** » Tue Apr 29, 2008 1:37 pm

Hello,

Using Drumagog in ProTools HD is also talked about in the manual, but here are the basics:

1. Use Drumagog Fixed Latency
2. Configure the Delay Compensation Engine (Platyback Engine Menu) to Long/4095 Samples per Channel
3. Enable Delay Compensation in the Operations Menu

I recently attended a Sweetwater workshop with Digi reps, and asked a product specialist about distributing processors on multi-core Macs. ProTools does not automatically detect these multiple processors, in that by default ProTools assigns all processing to 1 processor in the Playback Engine settings. If you are experiencing issues overall, you can distribute CPU processing usage evenly amomg the processors. Since Drumagog is RAM dependent, this CPU processor setting can effect other session factors. This in turn can effect Drumagog.

I do not own or have played with one of the 8 core Macs, but if someone would like to donate one, I'll take it off their hands

. Since Drumagog is RAM dependent, I am not sure if the RAM is distributed in the same fashion as the processors.

Drumagog functions fine with Leopard, so this issue does not have to do with your operating system.

Each GOG (Drumagog samples) are made up of multiple samples, and have dynamic groups. If your flams are not consistent with the dynamic group setting with a GOG, you can experience inconsistencies between downbeats/flams, and flams themselves.

By default, Drumagog Fixed Latency reports 80ms so that the ProTools and Drumagog can communicate this information, and reduce the latency that is perceived by your ears.

Nudging is somewhat of a last effort, but works well for the users that need to resort to it.

Hope this helps.

Mikey MTC · Post by **Mikey MTC** » Wed Apr 30, 2008 7:20 am

I haven't had a chance to verify this yet but based on my recent experiences I need to call you on a couple of these:

(1) Enable delay compensation and set it to long/4095.
Drumagog was telling Pro Tools that the latency was above this, somewhere in the mid 4's from memory, so Drumagog was breaking ADC. This was why I was manually defeating ADC on the Drumagog track and manually nudging the audio earlier by the declared amount. Had I not done this, there's no way the thing would be in sync and the big red numbers in Pro Tools' latency pane showed this.

(2) Pro Tools assigns all processing to one processor.
Ever since the dual G4 machines and the introduction of Pro Tools 7.0, Pro Tools has been able to address two CPUs or cores, as evidenced by the dedicated control for this in the Playback Engine section (that you mention). Mine currently defaults to 8. I thought it only became contentious when the processors went to 4 and now 8. The last rumor on this I heard was that it could only address 4 processors at this point in time, not 8.

All confusing reports - no wonder none of us can get on top of this stuff!
Thanks for the tips though Teri.

Teri · Post by **Teri** » Wed Apr 30, 2008 11:10 am

Mikey MTC wrote:I haven't had a chance to verify this yet but based on my recent experiences I need to call you on a couple of these:

(1) Enable delay compensation and set it to long/4095.
Drumagog was telling Pro Tools that the latency was above this, somewhere in the mid 4's from memory, so Drumagog was breaking ADC. This was why I was manually defeating ADC on the Drumagog track and manually nudging the audio earlier by the declared amount. Had I not done this, there's no way the thing would be in sync and the big red numbers in Pro Tools' latency pane showed this.

Because we are aware this can happen, the "Total Latency" is given to the user in milliseconds in the lower corner of the Main Tab. This enables the user to nudge the track if needed. The Fixed Latency/Delay Compensation setup typically works for most customers, but in an event that something happens to a user like Mikey, you can easily nudge the track.

(2) Pro Tools assigns all processing to one processor.
Ever since the dual G4 machines and the introduction of Pro Tools 7.0, Pro Tools has been able to address two CPUs or cores, as evidenced by the dedicated control for this in the Playback Engine section (that you mention). Mine currently defaults to 8. I thought it only became contentious when the processors went to 4 and now 8. The last rumor on this I heard was that it could only address 4 processors at this point in time, not 8.

Right, you are able to assign to multiple processors. I guess my point was that if you do not touch anything before conguring this in the Playback Engine, ProTools defualts to one processor. At least this is what I understood from talking with the Digi Product Specialist. So if the maximum is 4 processors, I'll take your word for it! Like I said, I haven't gotten to play with one of the 8 core Macs yet...

Mikey MTC · Post by **Mikey MTC** » Wed Apr 30, 2008 5:04 pm

Teri wrote: Because we are aware this can happen, the "Total Latency" is given to the user in milliseconds in the lower corner of the Main Tab. This enables the user to nudge the track if needed. The Fixed Latency/Delay Compensation setup typically works for most customers, but in an event that something happens to a user like Mikey, you can easily nudge the track.

As a matter of interest though, what is causing my example to blow out over the limit? Is it because of the Steven Slate Drums gogs I'm using?

watty · Post by **watty** » Wed May 07, 2008 8:13 pm

I'm getting the same thing but using a completely different setup. I'm on an Intel quad core PC set up using Cubase 4 and I experience frequent but inconsistent flam triggering of single strokes.

What's going on here? I can't use this software if it's going to do this.

shatzer · Post by **shatzer** » Wed May 07, 2008 9:31 pm

Never played with pro tools but from what i hear the program itself is pretty intense on power. I've had one issue with this problem before, and i dont know if this had anything to do with it, but unplugging some periphials (i took off my usb piano, usb pods, etc..) and the intensity on my cpu/ram lessened greatly.
I'm still in the dual core era with 2 gigs of ram on a Pc, but i'm still able to run 11 instances of Drumagog with Steven Slate samples, and numerous other plug ins along with it without any problems at all through Ableton.

Teri · Post by **Teri** » Thu May 08, 2008 11:42 am

Mikey MTC wrote: As a matter of interest though, what is causing my example to blow out over the limit? Is it because of the Steven Slate Drums gogs I'm using?

It could be. Because gogs contain multiple samples, recalling "large" gogs in real time could be the result of ProTools' sample reading.

watty wrote: I'm getting the same thing but using a completely different setup. I'm on an Intel quad core PC set up using Cubase 4 and I experience frequent but inconsistent flam triggering of single strokes.

Are you experiecing this issue with Drumagog Fixed Latency and the Auto Delay Companesion enabled in Cubase 4? Or have you tried working with the triggering engine settings on the Advanced Tab with Drumagog Regular Version?

shatzer wrote: I'm still in the dual core era with 2 gigs of ram on a Pc, but i'm still able to run 11 instances of Drumagog with Steven Slate samples, and numerous other plug ins along with it without any problems at all through Ableton.

Ableton and Drumagog work awesome together, we use Ableton for our trade show appearences with the kitchen set.

watty · Post by **watty** » Thu May 08, 2008 7:10 pm

Teri wrote:Are you experiecing this issue with Drumagog Fixed Latency and the Auto Delay Companesion enabled in Cubase 4? Or have you tried working with the triggering engine settings on the Advanced Tab with Drumagog Regular Version?

Hi Teri, thanks for replying. Been using the fixed latency version set to highest accuracy. I shall try tweaking it with the regular version if you suggest that's the better option.

Teri · Post by **Teri** » Tue May 13, 2008 12:33 pm

watty wrote:Hi Teri, thanks for replying. Been using the fixed latency version set to highest accuracy. I shall try tweaking it with the regular version if you suggest that's the better option.

Since you may achieve more desirable results, try using the regular version and work with the triggering engines (simple/live/advanced settings, sliding fader) and AutoAlign (bass/snare setting, actual/psychoacoustical) in the Advanced Tab. There is not one "set" option for optimum performance. Since every system is different, it takes a little experimentation on the users part.

If the Fixed Latency version/ADC configuration isn't working for you, try using the Regular version and tweak manaully.

chrisaiken · Post by **chrisaiken** » Sun Aug 17, 2008 10:16 pm

I'm getting the same thing...random mis-hits./flamming.

I'm running protools 7.4 HD on a g5 dualcore 2.3 with 8 gigs ram. ADC on 4095 samples. Fix latency. Using Steven Slate gogs.

Any of you with this problem find a solution?

I've tried every setting and combination I can think of. Simple mode seems to be a bit more consistent but the songs I'm working on have very fast fills and lots of flams in the playing so simple mode doesn't trigger well on the flams and fast parts.

I should also mention the mis-hit usually doesn't happen on the fast fills...it's usually just when the normal groove is playing.

Thanks,
Chris

Teri · Post by **Teri** » Thu Aug 21, 2008 1:50 pm

chrisaiken wrote:I'm getting the same thing...random mis-hits./flamming.

I'm running protools 7.4 HD on a g5 dualcore 2.3 with 8 gigs ram. ADC on 4095 samples. Fix latency. Using Steven Slate gogs.

Any of you with this problem find a solution?

I've tried every setting and combination I can think of. Simple mode seems to be a bit more consistent but the songs I'm working on have very fast fills and lots of flams in the playing so simple mode doesn't trigger well on the flams and fast parts.

I should also mention the mis-hit usually doesn't happen on the fast fills...it's usually just when the normal groove is playing.

Thanks,
Chris

Have you tried working with AutoAlign? Enabling/disabling in the Main Tab? Or working with the settings in the Advanced Tab (actual peak vs. psychoacoustical, etc.)?

chrisaiken · Post by **chrisaiken** » Thu Aug 21, 2008 2:28 pm

Thanks for the reply. Yes I've tried every combination I can think of and nothing seems to help.

For now I've figured out a work around....I set all the drumagogs to simple mode which for 80% of the track works well. When I have fast fills and flams I automate them to advanced to track these parts.

So far this has been working well. It's just this certain project that I'm working on where I'm having this problem....others are ok. It's a punk pop band and most tempos are 180 BPM or more and there's lots of 16th note snare fills.

Thanks,
Chris