MDrummer skipping notes

Hi there,

I have this issue: I create a simple gig, only MDrummer and the MIDI (Omni) blocks. Attach MDrummer to the output. Then I load a drumset, go to the rhythm editor, make sure there is a drumloop (by default there are). Then I press the ‘Play’ button (somewhere on top near the BPM/tempo signature) and then I start a loop using a midi note-on message e.g. C-1. This will start the leftmost beat loop. After a while (may take a few minutes!) MDrummer starts skipping notes. The problem is more clear when I use a more complicated loop like the default associated with F-1. Crank up the velocity of the ‘just to early’ bass note and snare note to make it more noticeable. Someone else have experience with this?

MDrummer version 15.00rc1
Gigperformer 4.0.54

I would like to upload the Gig and the audio example, but the forum tells me I’m new so I can’t.

I’ve changed your status to regular member so you should be able to upload now.

Thanks. (3.3 MB)
Drumloop Problem.gig (139.2 KB)

I’ve uploaded the gig and two resulting mp3 files (in the zip file). I may take a while, sometimes minutes before it starts. In the example drumploop-problem.mp3, however, it starts around 45 seconds. That is because I started recording after a while. The other mp3 I started recording when the issue occurred. Both use the same drum-loop (the one in the picture)

Hi @Frank1119, I think I am not the first to ask, but are you able to reproduce the issue is the MDrummer multi-core option is set to OFF?

Do you have other software running at the same time and what exactly?


Hi David,

Yes I tried that. Also I tried perfect sync on/off, sequencer mode on/off, GPU acceleration off/enabled/compatibility. No difference

I tried running Windows 10 in safe mode. Then almost nothing is running. Just enough to try it out using the inbuilt sound card. Same problem. To be complete also tried with virusscanner off.

Tomorrow I will try using my son’s computer. See if I can reproduce it there. He is not using it then, see he gave me permission to do that.

I didn’t realize you were in trial mode - are you taking into account that in trial mode the audio engine will randomly stop from time to time — that may very well be a factor.

No no, I’ve paid and I’m licensed: MDrummer as well as Gigperformer. When I want to set up thing on my son’s computer, I will have to transfer my licenses to his computer. Please don’t be confused. In my mind there is always this thing: ‘First Do No Harm’. So when I deactivate (I just saw I can do that in Gigperformer), there is always this little nagging voice in my head, questioning me whether I will be able to reactivate it on may own computer later on, or not. So therefore I rather like to keep things as they are and set up an environment in parallel.

It’s a bit of professional deformation. I’m in the infrastructure of a complicated business-network. There we always try out things in a separated network before deploying in the live network, because when we fail in production, it always fails bad. Can’t do that. Not really your problem :-).

In your email to me, you wrote " I already used the 14 day tryout" so it sounded like you were running the trial. Good that we can eliminate that as a possible cause.

Meh - we’re there to help you in such situations so don’t worry about that.

Yeah. I will try it out tomorrow and see whether I can reproduce it on other hardware. Now I trying if juggling the BPM just a little by script helps MDrummer or drives it just crazy. The latter I’m afriad

Well, now the conclusion…

Last year, I reported this issue (Gigperformer 4.1) and as far as I understand (I quote) “Nebojsa was finally able to reproduce the issue actually figured out the problem - it was VERY VERY subtle - but we have a fix now and it will be in a future release.”

The future was today: Gigperformer 4.5.8…

And now the verdict :grinning: (drum-roll please, pun intended) : The issue has been solved.

Thanks to everyone who spent time to investigate and solve this thing, especially Nebojsa, David, Vojtech.


I think it also solves the issue of MSuperLooper not correctly counting the bar length of the loop (it was previously undercounting by 1 on many occasions).