Halfway hihat pedal positions suppress hits of rolls

[ignotus]

I just tested and this definitely does not happen to me using an ARM board. AltFalseTrSupp is off and so is New Algorithm, no CC Reduction.

[anttipi]

To make sure MIDI CC causes the problem set HiHat pedal mode into Pot and see if you experience the same problem when the pedal is half way down.

When switched from foot controller to pot, the rolls trigger normally.

Also, make screenshots of Misc and Levels Pedal settings and a screenshot of Raw MIDI when you experience MIDI CC noise in a steady pedal position when the pedal is pressed half way down.

The first two screenshots are from ARM: one showing a glimpse of the CC data flood + Misc settings and the second showing pedal Levels settings.

For comparison, screenshots 3 & 4 are from Atmega. The only differences between relevant ARM vs. Atmega settings is different chick values and pedal curve, which however have no effect on the matter after changing them on ARM.

What can't be captured in a screenshot is the fact that on Atmega, the CC flow on halfway pedal positions is more stuttery, whereas on the ARM it's a continuous CC torrent. That is, with both at CC reduction 0.

[anttipi]

I just tested and this definitely does not happen to me using an ARM board. AltFalseTrSupp is off and so is New Algorithm, no CC Reduction.

Thanks for testing and letting me know.

What is baffling me is that, from what I have read here, CCs are not supposed be able to cause these kind of issues. I can of course turn CC reduction to 1 and the flood starts stopping/stuttering every now and then. But I'm not even sure how continuous or non-continuous the CC flow should ideally be and in my setup at least it certainly seems to matter (and like I wrote, BFD3 requires flowing hihat CC data for playing back recorded MIDI - but strangely in live playing BFD3 "remembers" the last pedal position even when the CCs stop. )

[dmitri]

If CC reduction is turned off and pedal level is not steady enough, MegaDrum will produce MIDI CC every time the pedal signal level change is enough for different CC levels. In your case it generates a MIDI CC every ~4-30ms. ~100 messages a second. Who or what will use so many MIDI CC messages? This seems a waste of resources on BFD3 part (or any other drum soft synth if behaves the same) if it needs a constant stream of MIDI CC for pedal positions. Why not just remember what was the last MIDI CC value. Obviously, if no newer MIDI CC has come, the pedal is in the same position.
If CC reduction is turned on, MegaDrum tries to reduce CC noise to make it easier for a soft synth to process it.
Can I ask you to test it over standard MIDI ports? I'm currently working on fixing a bug in USB which can cause loss of MIDI packets under very rare conditions.

[anttipi]

Dmitri, I'm wondering why the new pedal algorithm has weaker CC reduction than the old algorithm at identical CC reduction levels and if that might be changed in future firmwares? You said at some point that the new algorithm hasn't been thoroughly tested yet, so hopefully there'll be some improvement to that.

Because wiih the old pedal algorithm, I seem to get acceptable reduction levels via Megadrum's CC reduction settings but with the new algorithm even level 3 doesn't seem to be enough.

My brother, who is an engineer, thought the fluctuations sound like there's interference somewhere. He suggested I change the hihat controller cable to a better insulated microphone cable. He also gave me a capacitor to solder on to the plug too. I did that, but the issues remain.

If CC reduction is turned off and pedal level is not steady enough, MegaDrum will produce MIDI CC every time the pedal signal level change is enough for different CC levels. In your case it generates a MIDI CC every ~4-30ms.

Yes, I can definitely see that now, thanks for helping me out. Of course, fluctuating controller levels are interpreted by Megadrum as rapidly changing pedal openness.

This seems a waste of resources on BFD3 part (or any other drum soft synth if behaves the same) if it needs a constant stream of MIDI CC for pedal positions. Why not just remember what was the last MIDI CC value. Obviously, if no newer MIDI CC has come, the pedal is in the same position.

I'm not sure what's up with BFD3/Reaper, most probably it's just me. Reaper does record/"paint" a continuous CC level between two CC points. Maybe there is some setting in Reaper, which disables recording of overlapping CC data. It appears several "layers" of #4 CC data can be written on top of each other, instead of just overwriting all existing data when recording.

If CC reduction is turned on, MegaDrum tries to reduce CC noise to make it easier for a soft synth to process it.
Can I ask you to test it over standard MIDI ports? I'm currently working on fixing a bug in USB which can cause loss of MIDI packets under very rare conditions.

The roll suppression issue happens already on Megadrum's end, because of the insane CC flood.

[dmitri]

If CC reduction is turned on, MegaDrum tries to reduce CC noise to make it easier for a soft synth to process it.
Can I ask you to test it over standard MIDI ports? I'm currently working on fixing a bug in USB which can cause loss of MIDI packets under very rare conditions.

The roll suppression issue happens already on Megadrum's end, because of the insane CC flood.

This why I suggest you to test it with a standard MIDI - you may be hitting this USB MIDI bug in MegaDrum.

[anttipi]

The "lost CC data" issue (pedal position suddenly lost or "not remembered") can't be Megadrum-related because it has only happened when playing back already recorded MIDI via BFD3 in Reaper. Hihat sounded normal when playing it live during recording.

BTW, I'm ordering a new Honeywell or Allegro hall sensor as they're so cheap anyway. Operating range of 4,5 - 10,5 V is a sufficient spec for Megadrum, right? I have no idea if the mV/g rating has any effect on the noise characteristics of the sensor, mine right now is 5 mV/g (whatever that even means). I've read Honeywell SS490 has worked with Roland gear so I'll be ordering an SS495, which should be similar. Anyway, I would have thought any linear hall sensor would do (?).

[anttipi]

Ah, I just realized ignotus wrote he uses an AU1302 hall sensor successfully. I'll get one of those. The AU1302 appears to be less sensitive than my current sensor (~1,5 mV/g vs. 5 mV/g), which might explain why mine is acting all "nervous".

[ignotus]

Specifically this one: https://www.bitsbox.co.uk/index.php?main_page=product_info&cPath=302_305&products_id=2083&zenid=8aakgdr3oqmeln8ojvgo4243t1

[dmitri]

If CC reduction is turned on, MegaDrum tries to reduce CC noise to make it easier for a soft synth to process it.
Can I ask you to test it over standard MIDI ports? I'm currently working on fixing a bug in USB which can cause loss of MIDI packets under very rare conditions.

The roll suppression issue happens already on Megadrum's end, because of the insane CC flood.

This why I suggest you to test it with a standard MIDI - you may be hitting this USB MIDI bug in MegaDrum.

The "lost CC data" issue (pedal position suddenly lost or "not remembered") can't be Megadrum-related because it has only happened when playing back already recorded MIDI via BFD3 in Reaper. Hihat sounded normal when playing it live during recording.

Do I understand it right that you don't have a problem with lost notes(apparent rolls suppression) when the pedal is half pressed and you're not going to test it over standard MIDI?