John T

Beepster
Another question... are these delays enough to cause audible flamming between the original and the replacement sample(s)?

No. I wouldn't have noticed it if I hadn't zoomed in really close to do something else.

I wouldn't worry about it too much then. In fact it may be operating as intended. Perhaps if it slid the samples in exactly how you are envisioning the result would be less desirable. It may look at the overall sample as opposed to the very start and then make a judgment call as to what will make the replacement occur in the most natural way.
 
Like a kick with a slow attack and release being replaced with a tighter one that has a fast attack and release gets centered so the meat of the kick lands where it needs to to stay on time. If it was nudge to the very start of the original hit it may sound too soon and not last as long.
 
Just a thought. I have no idea if that's how it actually works. That would be pretty impressive though.
 
Cheers.
 
Edit: I just realized that may not make sense since the bounce is not reflecting the original replacement processing. However neither does a lot of Online rendering stuff versus offline so maybe the render process does something extra to make it tighter. Really though you should probably just ignore my blathering. Just trying to understand.

Hey Y'all
 
I don't have a [Cakewalk] tag yet but I was involved with the hit detection algorithm used in Drum Replacer. We're working on some ideas on making it more sample accurate, but it's kind of a tough problem. Ideally the sample position would line up exactly, and I think we can do a lot better, but I'd say it's doubtful that we're going to have perfect sample alignment, especially with noisier tracks. 
 
However, to make a useful point, the lag you're seeing is most likely not due to bounce or any driver issue, but small errors in the algorithm that were not large enough to be audible. 
 
- John