Inconsistent MIDI command triggering in MDrummer Large

[MeldaProduction]

Ok, so let's wait for the beta (feel free to contact me via info@meldaproduction.com and I'll add you to the beta group). I'm going to send it to the group in a few hours tops.

[Gamma-UT]

OK thanks. I can wait as I've got a workaround that works. But if you want another tester for it, let me know.

[goldglob]

I think I might have the answer to this problem (in Reaper at least and possibly in other DAWs).

Even though MIDI ticks are equated with beats (E.G. 1 quarter note = 960 ticks), snapping MIDI notes to the grid actually snaps to a tick grid that starts from the MIDI item start and is not neccessarily lined up with the DAW beat grid. So, if your MIDI item start is not snapped to DAW grid your MDrummer MIDI notes will be off the DAW grid even though you had snapping on.

See this thread on the Reaper forum. https://forum.cockos.com/showthread.php?t=184790

There are reasons for having it like this and for normal MIDI stuff the discrepancies are so minute as to be un-noticeable, but for MDrummer it's a problem...MDrummer needs the note to be exactly on the DAW grid. Seems like the solution is to make sure your MIDI item starts on the grid...unless Vojtech can do some insane maths that deals with this....by seeing the 'real' tick as the trigger... or something?

Having said all that, why does this happen only on beats? I thought it might be that breaks usually don't have a hit on the start of the bar, giving MD time to re-think, but no, even breaks with hits on 1 (but slightly late by tick) still trigger.

[Gamma-UT]

Good spot. That does seem to correlate with what I'm finding. Live might be a lost cause in trying to get down to tick resolution. However, in Logic, you can edit note events directly to the tick scale without having to zoom in to the finest scale in the piano roll. With a note set to the first tick of the second bar (Position '2 1 1 1' in Logic's event list), MDrummer starts the corresponding beat 'late'. But moved just one tick earlier to '1 4 4 240' (on a 4/4 signature), it works.

My hunch is that, with Logic, MDrummer regards 'tick zero' of the second bar as being the last tick of what Logic sees as the previous bar and '2 1 1 1' as one tick too late.

Live's behaviour is a bit more odd but does give a clue as to how its timing engine links MIDI and audio. At 120bpm, MDrummer triggers beats as it should. I didn't notice this at first as the project I was testing in was around 135bpm. Move one 1bpm in either direction from 120bpm and it's all over. At 240bpm it works again. So it seems the DAW timing grid and the MIDI don't align except at bpms that neatly divide into the DAW timing grid (and they just happen to be a factor of 960). At other bpms the grid seems to be fractionally off, so any note event needs to be moved to an earlier point to compensate for that slack. And it's not a fixed amount. Logic appears to handle timing differently to Live - MIDI came first in Logic-world. With Live it was the other way round so its handling of MIDI isn't unexpected.

[goldglob]

Yep, seems to be a ticks vs DAW beats thing....and further to what I said about the MIDI item's start having to be snapped to DAW grid: let's say I've created a MIDI item willy-nilly without snap on.. it's not enough to then just snap the item edge to grid...the whole item has to be moved (with snap on) to start on the grid...only then will the 'item ticks' line up with the DAW grid.
But I ask again...why is it just beats (not breaks etc) that need this?

[Chandlerhimself]

My guess is that beats and breaks opperate differently. Beats always start at the first note of the bar, so if they are triggered late it causes that bar to be skipped and the beat will play on the next bar. Breaks are usually played on the 3rd or 4th quarter note of the bar, so even if you don’t have the midi lined up exactly with the beginning of the bar you’re still usually 1 or 2 quarter notes early, giving MDrummer plenty of time.

[goldglob]

My guess is that beats and breaks opperate differently. Beats always start at the first note of the bar, so if they are triggered late it causes that bar to be skipped and the beat will play on the next bar. Breaks are usually played on the 3rd or 4th quarter note of the bar, so even if you don’t have the midi lined up exactly with the beginning of the bar you’re still usually 1 or 2 quarter notes early, giving MDrummer plenty of time.

I had thought this too, so to check I created some breaks with hits at the beginning of the bar.... I found that the behaviour was the same...'tick late' beats don't trigger, 'tick late' breaks do trigger. But this doesn't negate what you are getting at, and when you consider that breaks are designed to allow the previous beat to continue until the actual break hits occur it seems that break triggering is linked to the actual hits whereas beat triggering is linked to the start of the MIDI command....and so if a break hit at the beginning of the bar is 'tick late' it doesn't matter, it will be triggered.

[MeldaProduction]

Ok, so I have bad news - this cannot be solved on our side. So what is happening here:

- If you trigger a break/long break/outro/intro it can start any time, after all drummers are often starting, well, anywhere... Sometimes because they forgot . At the moment of the command MDrummer either switches immediatelly or whenever possible, in case the break (or other loop) starts actually later.

- If you trigger a beat the situation is different - the command must be known at most at the moment of the start of the bar. It is always planned for the next bar with the exception of the position 0 in the bar (because it just makes sense). If the command arrives a single sample later, it's too late... MDrummer might have started playing new notes already and for all he knows it may be just impulses, which would mean that the notes have in fact already finished!

Most hosts seem to provide correct timing, Live doesn't... At the moment it sends the command it is position say 0.0001 in the bar, which seem like a little, but as I explained, it's just too late, the drummer already started playing...

Perhaps Live has some delay feature? (Cubase does) So you could move the whole track a millisecond early and it should be fine then. Or just remember to move these problematic notes.

[goldglob]

Vojtech, yep that fits with what I was thinking. It might be worth briefly mentioning this anomaly in the MDrummer docs, something like:
" MIDI commands for beats should be snapped to bar lines but because of the technicality that DAW timing does not always line up exactly with MIDI tick timing, snapped commands can actually end up very slightly later than the bar line. It is therefore suggested that if MDrummer is not triggering beats as expected just nudging all the beat commands a millisecond early should solve the problem"....I dunno, it's hard to express this succinctly...have a think about it one Sunday morning when you're not busy...haha.

[MeldaProduction]

Hehe true, but news here - 99% people don't read documentations, so it wouldn't really help . This is the inevitable minefield of complex tools MDrummer...

[Gamma-UT]

Hehe true, but news here - 99% people don't read documentations, so it wouldn't really help . This is the inevitable minefield of complex tools MDrummer...

It would have helped me. I did work out how to deal with the issue but I spent more time than necessary chasing my tail because things weren't working as described in the videos or the documentation. I think just saying "if beats don't trigger on at the start of a bar, move the trigger to an earlier position" would help people.

[MeldaProduction]

Very well, then I'll add it!

[Gamma-UT]

Very well, then I'll add it!