Halfway hihat pedal positions suppress hits of rolls

[dmitri]

As a temporary solution I would suggest to try 0.1-1.0uF capacitor between ground and the signal wire of the pedal.

[anttipi]

As a temporary solution I would suggest to try 0.1-1.0uF capacitor between ground and the signal wire of the pedal.

I've already tried with a capacitor between power and ground. I can get another from my brother to try between signal and ground.

[anttipi]

I finally got my brother to look at my MD. He only had time for a quick visual inspection ("well, nothing seems loose inside" ), and I will not be able to push him to do much else because he's too busy.

Dmitri, how does MD handle the CC message suppression, if - like in my case - there's an insane amount of up to 100 messages per second to suppress? Does the filtering actually ease up the load on the processor or is the MD still continuously overloaded in the background even though I don't see the CC flood because of CC suppression?

I'm asking because even with CC suppression at 3, I occasionally still get a weird feeling that MD might be somehow struggling (like a lost or slightly stuck/delayed hit maybe). Dunno, maybe it's placebo so I'd really like to know.

Anyway, I'm stuck with what I have right now and just trying to make the best of it as I have an album to record (and I'm lagging behind schedule).

[dmitri]

In simplest terms, CC suppression works like this.
1. With no suppression, if MegaDrum detects change in HiHat position it sends a new CC04 with a new position value.
2. With suppression enabled, if MegaDrum detects change in HiHat position it first checks if the level difference between new position and the last sent CC04 value. If it is below threshold, it doesn't send anything, otherwise it sends CC04 with a new position.

[anttipi]

In simplest terms, CC suppression works like this.
1. With no suppression, if MegaDrum detects change in HiHat position it sends a new CC04 with a new position value.
2. With suppression enabled, if MegaDrum detects change in HiHat position it first checks if the level difference between new position and the last sent CC04 value. If it is below threshold, it doesn't send anything, otherwise it sends CC04 with a new position.

So am I right in concluding that sending excessive amounts of CC04 is the part that causes an overload in Megadrum and not detection per se of rapidly and continuously varying HiHat position changes (a.k.a. filtering out interference)?

In other words, with CC suppression enabled to filter out hihat controller interference, MD is in practical terms not forced to waste any more resources than it would need to when the hihat controller data is stable?

[dmitri]

You are correct.

[anttipi]

You are correct.

Thanks for the clarification.

[anttipi]

It looks like the ARM is not providing nearly enough volts from the hi-hat controller output?

While touching ground with the voltimeter's black probe and simultaneously tip or ring (sorry, not exactly sure which is which on the stereo plug) with the red probe, I get the following readings:

When connected to older Atmega: 2.1 V and 4.3 V.

When connected to Arm: 1.5 V and 3.2 V. I tested with two different cables (and different set of plugs), two different hall sensors (of different brands), two different PCs, two different USB cables. It's always ~3.3 V max. Without hall sensor attached (measured with a regular stereo cable), the ARM does seem to provide ~4.8 V from the hi-hat controller output but it drops to 3.2 V as soon as a hall sensor is on the other end of the cable. Both sensors I tested with have been proven by others to work in this application (Allegro UA1302 and Honeywell 495A). I think I've been through five sensors by now.

Like I wrote earlier in the thread, there's an instability of CC values (hi-hat openness level) even with CC reduction at max and it's making the ARM Megadrum almost useless for me. On the other hand, on the Atmega, CC reduction at 1 already limits almost all of the excess CC's. Dmitri, is the voltage difference between Atmega and ARM explaining this perhaps?

[dmitri]

Both Atmega and ARM version provide power to the HiHat controller over 100 Ohm resistor from 5V. All I can suspect is that your old Atmega module uses Yamaha polarity while all all module I build use Roland polarity. See viewtopic.php?f=3&t=3253
If this is not the case then I can suggest you to send your sensor to me to investigate.

[anttipi]

Both Atmega and ARM version provide power to the HiHat controller over 100 Ohm resistor from 5V. All I can suspect is that your old Atmega module uses Yamaha polarity while all all module I build use Roland polarity. See viewtopic.php?f=3&t=3253
If this is not the case then I can suggest you to send your sensor to me to investigate.

I use a cable where polarity is reversed, i.e. both Megadrums were in their default "Roland mode" during the tests (in my Atmega, the polarity is also switchable from the front panel).

As hall sensors require ~4.5 V minimum and other people apparently have had no such problems, I assume the 3.2 - 3.3 V output under load has something to do with the interference/instability issue I'm encountering? I mean I should be seeing well over 4 V on the voltimeter, right? I have minimal experience in electronics so I don't know what a voltage drop from 4.8 (with just cable plugged in) to 3.2 (with hall sensor) really implies. All I know is according to the hall sensors' specs the sensors should be getting at least 4.5 V, so something is not right.

I would certainly appreciate it if you could have a look at it because the ARM has been behaving like this since day one. In several other respects it's been a worthwhile improvement over the Atmega but this issue seems to be interfering with hit detection at times.