www.megadrum.info

I'd like some input on some latency and aftertouch issues, perhaps Dmitri could share his thoughts on the below points?

1. When playing a very busy beat, MD sometimes fails to register some individual hits. For example a snare hit (not part of a roll but a regular semi-hard hit) may not register every now and then. This is on an ARM MD which should have more than enough processing power, right? The MDM MIDI log seems to confirm that the hit is indeed missed and thus not a software issue on the PC side. What setting if any in MD would contribute to this issue? The pads are all set up properly and it's not a case of thresholds being too high etc. These dropouts only happen when there is a lot of triggering happening from various pads (like busy ride bell hitting along with hihat chicks).

2. Despite latency generally being fine, I sometimes experience (individual) sounds being produced with a longer than expected delay. MDM seems to indicate it's NOT a Megadrum issue. PC is optimized for audio. CPU or RAM are nowhere near maxing out and I can use my RME AIO soundcard at 32 samples without any crackles. So I'm starting to think it can only be BFD3 that I'm running as a VST3 in Reaper (on Win 64bit). Have I missed something in the BFD3 setup, like MIDI shouldn't perhaps be set to "omni" etc.?

3. I'm getting Aftertouch messages from note 0 from my hihat pad once every 10 secs or so, and this happens regularly when not even hitting the pad. How can this happen when I haven't even assigned note 0 to the pad? It seems to originate from the Edge threshold. At 36 I get satisfactory edge triggering AND the Aftertouch messages from note 0. When lowering Edge to 35, the note 0 Aftertouch messages stop BUT edge triggering is compromised in favour of bow. I use edge on the hihat much more than bow so I prefer to keep it at 36. The question is, are the Aftertouch messages "harmful"? They are happening on an unused note so I guess I can just ignore them?

1. Without more detail I can only suspect that a missed hit is due to too aggressive XTalk suppression between several pads in the same XTalk Group or due to to aggressive double triggering suppression (DynTime/DynLevel).
2. Don't know about what may cause periodic audio delays. IT can be due to CPU usage spikes or disks access. What I can say for sure is that if BFD is set to listen on all MIDI ports then you'd better set 'MIDI2 for Sysex Only' in MegaDrum or configure BFD to listen only one of two MegaDrum ports.
3. I'm not too sure I understand what the problem is from the description. A pad/cymbal which has Notes in all zones assigned proper numbers (not disabled) then it cannot produce Aftertouch with Note 0. Maybe you have some other inputs configured as piezo/switch with one of the zones disabled and where Threshold on the switch is set right on the border between make/break levels?

dmitri wrote:1. Without more detail I can only suspect that a missed hit is due to too aggressive XTalk suppression between several pads in the same XTalk Group or due to to aggressive double triggering suppression (DynTime/DynLevel).

DynLevel on the snare is only 4 and DynTime 0 with Retrigger at 1, so I'm sure it can't be that. XTalk is at 0 on the snare. Some pads have XTalks higher than that but I don't think XTalk values of other pads should affect the snare at all, even when in the same XTalk group?

It feels to me like MD's processing gets overwhelmed with too much triggering (just a wild guess). So I tried raising Latency but it didn't make any difference. Could also be BFD3 getting overtaxed and dropping notes but anyway MDM seems to confirm some odd hits are missed already on Megadrum's side. Hard to be sure.

2. Don't know about what may cause periodic audio delays. IT can be due to CPU usage spikes or disks access. What I can say for sure is that if BFD is set to listen on all MIDI ports then you'd better set 'MIDI2 for Sysex Only' in MegaDrum or configure BFD to listen only one of two MegaDrum ports.

I disabled the other MD MIDI port in BFD3, will have to see how it works out. I had completely missed that setting because the setting is only visible in the standalone mode and I exclusively use BFD3 as VST3 in Reaper.

CPU usage remains low and there's no bottlenecking from disk access either as the samples are on a dedicated SSD.

3. I'm not too sure I understand what the problem is from the description. A pad/cymbal which has Notes in all zones assigned proper numbers (not disabled) then it cannot produce Aftertouch with Note 0. Maybe you have some other inputs configured as piezo/switch with one of the zones disabled and where Threshold on the switch is set right on the border between make/break levels?

It's only a problem for me if it's somehow harmful/detrimental to have Aftertouch messages every few seconds or so from notes that are not assigned to any sounds? I would guess it doesn't matter much as Aftertouch is not firing continuously.

To recap, the hihat pad is sending Aftertouch on note 0 even though note 0 is not assigned anywhere for that pad. Unplugging the hihat from MD stops the messages. Also, when I enable AltNote Aftertouch, AltNote of the hihat is sent in place of note 0. Lowering Edge by 1 stops all this but then I compromise edge/bow separation.

I do have note 0 assigned for several other pads in the kit but unless I'm misunderstanding something, it must be the hihat pad sending the Aftertouch messages, based on what I wrote above about troubleshooting the issue.

anttipi wrote:Some pads have XTalks higher than that but I don't think XTalk values of other pads should affect the snare at all, even when in the same XTalk group?

Try putting the snare into a separate XTalk group with no other pads in the same group.

It's only a problem for me if it's somehow harmful/detrimental to have Aftertouch messages every few seconds or so from notes that are not assigned to any sounds? I would guess it doesn't matter much as Aftertouch is not firing continuously.

To recap, the hihat pad is sending Aftertouch on note 0 even though note 0 is not assigned anywhere for that pad. Unplugging the hihat from MD stops the messages. Also, when I enable AltNote Aftertouch, AltNote of the hihat is sent in place of note 0. Lowering Edge by 1 stops all this but then I compromise edge/bow separation.

The must be note 0 somewhere then on the HiHat. Post the screenshot of settings with which you are having problems. I also would suggest to raise Gain to make the levels range for detecting switch break/make and raise/re-adjust Threshold on the switch.

dmitri wrote:Try putting the snare into a separate XTalk group with no other pads in the same group.

OK, will try that. For the heck of it, I think I'll assign each of the available XTalk groups to individual pads, just in case. Not that I ever have experienced crosstalk issues though, due to much of the kit being installed on separate stands.

The must be note 0 somewhere then on the HiHat. Post the screenshot of settings with which you are having problems. I also would suggest to raise Gain to make the levels range for detecting switch break/make and raise/re-adjust Threshold on the switch.

I just realized the hihat does output Aftertouch on the correct note - but only sometimes!

Here's how it goes:
1. I stard MDM
2. MIDI log starts showing Aftertouch from note 0
3. I play the hihat pad
4. Aftertouch messages switch to the correct hihat notes
5. I stop playing
6. After a while, the Aftertouch starts coming from note 0 again!

Here's a screenshot showing alternating Aftertouch notes:

Please post your complete .mds config file here (zipped).

dmitri wrote:Please post your complete .mds config file here (zipped).

Will do that tomorrow.

In the meantime, I can say the other issue I was referring to in this thread (perceived lagginess or "sticky" response) seems to have been mitigated by enabling AltFalseTrSupp.

It seems to me the default false triggering suppression is just way too strong for my needs, because even with DynLevel/DynTime at 0 on the hihat, I'm struggling to get a sensitive enough response. The hihat feels better with AltFalseTrSupp enabled - there's also a lot more tweaking headroom now with DynLevel/DynTime.

I just need to get past my mental block of thinking of the alternate algorithm as "suboptimal" only because it's "older".

I just noticed that you enabled 'Alt Sampling Alg' - I suggest you to disable it. It has not been tested thoroughly and hardly any one uses it. It is very different from the standard sampling algorithm (and it was not available in Atmega at all) and will affect (positively or negatively) pretty much everything.

dmitri wrote:I just noticed that you enabled 'Alt Sampling Alg' - I suggest you to disable it. It has not been tested thoroughly and hardly any one uses it. It is very different from the standard sampling algorithm (and it was not available in Atmega at all) and will affect (positively or negatively) pretty much everything.

I wonder why it is not used by more people... I had big a headache getting with my 22'' A2E mesh Kick Drum to work consistently... After switching to Alt Sampling Alg it's working almost perfect with MinScanTime down to 25... I think the old alg. is looking for peak values in the incoming signal while the Alt alg. is RMS-ing it...

On the other hand I think I've experienced some miss-hits as well, but I didn't give too much thought because the whole kit thing isn't put together yet... Still focusing on getting good stick response from the mesh heads and minimum retrigger suppression parameters...

dmitri wrote:I just noticed that you enabled 'Alt Sampling Alg' - I suggest you to disable it. It has not been tested thoroughly and hardly any one uses it. It is very different from the standard sampling algorithm (and it was not available in Atmega at all) and will affect (positively or negatively) pretty much everything.

Wow, thanks for the tip!

After disabling Alt Sampling:
- Much better edge/bow separation on the hihat
- Gain settings work now (see viewtopic.php?f=3&t=3160&p=31789#p31789). I was only able to use Gains 7 or 8, now I can finetune levels like "in the old Atmega days" using the whole setting range.
- No more false Aftertouch messages from the hihat when the Edge threshold is at the optimal value for edge/bow separation

I haven't tested for sensitivity yet. I may still opt to use AltFalseTrSupp because it gives more room to tweak DynLevel/DynTime (instead of getting too much suppression even at DynTime/DynLevel at zero on certain pads).