Piezo/rim/rim (3-zone) cymbals

[3hhh]

After our discussion I had another look at the edge/rim vs bell signal of such a pad and observed the following key points:

1. The rim switches just duplicate the piezo signal to the second audio channel. They do not switch it!
2. The duplicated channel is much more shallow than the primary channel. This is possibly caused by the choke functionality (low input impedance), which causes the piezo signal to diminish much more quickly?
3. The bell signal is even more shallow than the edge signal. This is likely caused by the additional resistor used to distinguish it from the edge signal.

Based on these observations I believe that a possible algorithm to support these kind of pads could work as following:

1. Decide whether a hit is a regular hit or rim shot as before (i.e. via rim threshold).
2. On rim detection compute |[channel 1] - [channel 2]|. If that difference is above a certain threshold, the piezo signal represents the edge. If it's below that threshold, it represents the bell. It may be the other way around for other pads (depends on where the vendor places the additional resistor).

If that doesn't work, it may be necessary to amplify the difference in hardware. Anyway I think the difference is the key here.

Another option from looking at the signals may be to decide based on the length of the power ripple, but I'm not sure whether that works for all of these pads.

What do you think?

[corrados]

That's an interesting finding. But since the contact of the stick to the pad is so short, I hardly believe that the signal you see is purely coming from the pad. Maybe some Teensy ADC cross talk is also taking place here. Or the switch in the pad sticks to the contact for a short time after the strike.

Anyway, can you please share a screen shot of these signals?

If the rim signal looks like the normal pizeo signal, in that case it may be beneficial to use pad_settings.is_rim_switch = false for this pad. Maybe you could do the threshold test you did for the case pad_settings.is_rim_switch = true for the case pad_settings.is_rim_switch = false again. Maybe in that mode you can find a threshold to distinguish both. At least, if you see a difference in signal amplitude in the test you just did: The bell signal is even more shallow than the edge signal then there is still a chance that a threshold may be enough to detect that difference in signal level as well.

[ignotus666]

The rim switches just duplicate the piezo signal to the second audio channel. They do not switch it!

I really don't understand this. The two channels (piezo-> tip / switch-> ring) are isolated from each other and only share ground. What the switch does is short its input to ground. When it does that, it's telling the module "hey, a switch input was hit, trigger my MIDI note and not the bow note". I thought it would be easy to distinguish whether an analog input was shorted to ground through a resistor or not (to know which switch has closed), but it doesn't seem to be the case.

Then, to assign a velocity to the hit, the module uses the signal from the piezo. If you're seeing weaker signals on edge and bell hits, it's likely because those hits are further away physically from the piezo. But there's no way you're seeing a piezo signal on a switch input - at most it's the switch bouncing.

[3hhh]

Hi again @ignotus666 .

It's much appreciated that you're joining this thread!

My understanding of rim switches comes from https://hub.yamaha.com/drums/d-electronic/how-do-electronic-drums-work/, which indicates that a rim switch switches the piezo signal to a different output, when hit ("diverts the spike down a different part of the cable").

Since my signal looks like this

(top is bow, middle edge, bottom bell) and the bottom two look like piezo signals, I was under the impression that this was correct (apart from the fact that the signal looks duplicated rather than switched).

However I also already confirmed that the input impedance goes to 31k and 36k depending on which switch is hit. Unfortunately that seems to be too insignificant of a difference to be observable with the 10 bit ADC.

[corrados]

For those who are interested in your measurement results and cannot read your txt files, I have loaded them in Octave with

f='bell_hard1.txt';x=load(f,'-ascii');figure;plot(x);title(f)
f='edge_hard1.txt';x=load(f,'-ascii');figure;plot(x);title(f)

and made a screen shot of the plots:

[corrados]

BTW, here is a link to a nice forum post about 3-zones Yamaha pads.

[corrados]

And here is another link from the HelloDrum-library:
https://github.com/RyoKosaka/HelloDrum-arduino-Library/blob/master/docs/circuit.md
using the following schematics.

[3hhh]

One question to your schematics: Why are you using 100k for Rp? Why not a lower value like 10k instead? The current would be still low enough but the voltage difference would be higher between bell and rim.

Hm, Rs is 31k or 36k in my case.
So with Rp=100k we have 31/131*3,3V = 780mV vs 873mV for36k. With Rp=10k we have 31/41*3,3V = 2495mV vs 2582mV for 36k. Not much of a difference imho. Also, Rp=100k works with a lot more values for Rs than Rp=10k and the drop is more obvious - that's why I chose it.

For my pad in particular it seems that the edge switch is on for a way longer time than the bell switch which makes it discernible.

That may be caused by the fact the striking the edge with the stick will longer close the switch than hitting the bell and not be caused by the additional resistor.

If that's true, it would be a generic method to detect the bell.

I do not understand why both measurements you did for bell/edge go to 0 V. How did you record these signals? Is it recorded with Edrumulus where the DC-offset was subtracted or is it the pure ADC signal without any modifications of the digital signal?

It is the pure ADC signal, cut off at 3V. I used a simple non-edrumulus sketch without any DC offset correction.

However I also don't fully understand why it goes down to 0V. Apparently something's drawing current...

[corrados]

For my pad in particular it seems that the edge switch is on for a way longer time than the bell switch which makes it discernible.

That may be caused by the fact the striking the edge with the stick will longer close the switch than hitting the bell and not be caused by the additional resistor.

If that's true, it would be a generic method to detect the bell.

Ok, but then we would not need the 10k resistor inside the pad at all. So, it must exist a solution to distinguish bell from edge using the 10k resistor.

Maybe it's worth looking at the HelloDrum library since it claims to fully support such pads. Do you have an Arduino available for testing?

[3hhh]

On 11/21/23 22:42, Volker Fischer wrote: Maybe it's worth looking at the HelloDrum library since it claims to fully support such pads.

According to [1]: bow = (velocity > Threshold && firstSensorValue < edgeThreshold && lastSensorValue < edgeThreshold) edge = (velocity > Threshold && firstSensorValue > edgeThreshold && firstSensorValue < cupThreshold && firstSensorValue > lastSensorValue) cup = (velocity > Threshold && firstSensorValue > cupThreshold && lastSensorValue < edgeThreshold) choke = (firstSensorValue > edgeThreshold && lastSensorValue > edgeThreshold && lastSensorValue >= firstSensorValue) So apparently HelloDrum uses two different thresholds and two measurements (peak & last measurement at the end of the scan time). [1] https://github.com/RyoKosaka/HelloDrum-arduino-Library/blob/master/src/hellodrum.cpp#L497 Do you have an Arduino available for testing? No, just the Teensy. Maybe I'll try the 10k when I have some spare time to see whether the voltage doesn't drop to 0V with that.

[3hhh]

A few more sample images with 10k and 100k resistors - this time really at 8kHz (before it was unlimited/about 240kHz due to a bug in my code - delay() doesn't accept floats):

Lemon (first 100k, then 10k, cut off at 1.8V/2.6V):

MPS 750x edge (first 100k, then 10k, cut off at 3.1V):

MPS 750x bell (first 100k, then 10k, cut off at 3.1V):

What I see from them:

• All go through 0V.
• The Lemon rim switch behaves pretty much the same with both resistor values. The offset changes though (apparently it draws current?).
• The MPS750x edge switch remains closed for a way longer time than the bell switch. Rp=100k seems to make the difference even larger. Maybe the current needs more time to flow through the 100k resistor and thus keeps the switch closed for a longer time? Idk.
• Unfortunately no clear way to identify the different input impedances between edge and bell.

So I still believe that the time difference/number of samples below the threshold is the best way to discern bell and edge. I guess it would make sense to verify this on other similar pads though. Someone with more analogue circuit expertise might also be helpful.

[3hhh]

Another option is to use the lowest peak with two different thresholds to discern edge and bell as discussed. However that requires a careful choice for C1 as the Lemon sample from above proves (C1 was apparently too small for the Lemon hihat).

[3hhh]

If yes, why should the Yamaha pad draw less current than your Millenium pad? It is also just a switch.

I don't have a Yamaha pad to double check. I however checked with the two pads from different manufacturers I have and they both exhibit the same behaviour. Feel free to double check with your Roland pads (you can manually put a resistor in between the bell and edge output after all).

[3hhh]

Btw the Lemon simply draws more current as the input impedance is lower by around 30k than the Millenium pad input impedance. Possibly the Yamaha input impedance is higher, idk.

[3hhh]

Is anyone willing to double check my statement wrt the signal duration of bell vs edge on piezo/rim/rim cymbals with different hardware than mine @corrados @ignotus666 ?

The second threshold implementation would probably also work with the capacitor circuit from above (see the diagrams). However the capacitor needs to be chosen based on the specifics of the cymbal (as can be seen from the Lemon example above), i.e. imho no generic circuit working for everyone can easily be designed.
The duration method - if viable - seems way more stable for this very reason.

Both methods would only look at a small part of the diagrams above (first 50-100 samples or so). The remaining samples nonetheless need to be ignored for e.g. the DC offset update to avoid issues. This is one of the areas where the current implementation is lacking.

[corrados]

I am still thinking that it makes sense to find out why a simple threshold works for the HelloDrum library but not for you.

[3hhh]

On 12/8/23 21:08, Volker Fischer wrote: I am still thinking that it makes sense to find out why a simple threshold works for the HelloDrum library but not for you.

So you tested the simple threshold without capacitor and it worked for you? Imho hellodrum is just some other open source software where the author possibly got it to work with one particular piece of hardware s/he owned. Just because s/he got it to work once doesn't mean it works for everyone or could even be considered as some sort of reference implementation. Anyway as I've said: It would work with the capacitor circuit for me as well, but only if the capacitor value is chosen specifically for the respective piece of hardware. So if you insist on that particular implementation, I can get it to work for me as well. It's possibly just not the best way of doing it.

[corrados]

It would work with the capacitor circuit for me as well

What about the latency you get with your algorithm?

[3hhh]

On 12/9/23 09:32, Volker Fischer wrote: > It would work with the capacitor circuit for me as well What about the latency you get with your algorithm?

What algorithm? The ones I mentioned so far are obviously wrong as per my later findings. This discussion doesn't look constructive to me anymore. Feel free to close it.

[3hhh]

What about the latency you get with your algorithm?

What algorithm? The ones I mentioned so far are obviously wrong as per my later findings.

I was referring to your statement: "So using a threshold on the number of observed samples is very likely the correct way to implement this.". If you use a capacitor and you need some settle time, it will introduce delay. This was my concern.

I see.

Ok, let's have another look at the diagrams:
Without the capacitor it's possible to decide bell vs edge for the MPS 750x after ~30 samples = 3,75ms with a threshold of 3V using the sample counting method.
With the capacitor one would need ~150 samples = 18,75ms at a threshold of 2,6V.
So yes, counting the samples is faster at small/non-existent capacitor values.

Let's compare it to the threshold method, which definitely requires to carefully choose the capacitor (at least in my case):
After 30-50 samples and the thresholds 2V (edge) vs 2,6V (bell) one can decide bell vs edge.

The current edrumulus code just uses the scan time (2,5 to 6ms depending on the pad), which isn't great as the rim switch apparently tends to remain closed for up to ~120 samples = 15ms (with the capacitor it's even way more) and the remaining time affects the DC offset etc.

[corrados]

Without the capacitor it's possible to decide bell vs edge for the MPS 750x after ~30 samples = 3,75ms with a threshold of 3V using the sample counting method.

3.75 ms would be ok for me. But if you look a the overall commercial modules latencies, that value is still quite large.

With the capacitor one would need ~150 samples = 18,75ms at a threshold of 2,6V.

That latency would be unacceptable for me.

The current edrumulus code just uses the scan time (2,5 to 6ms depending on the pad), which isn't great

This, I don't understand. Do you mean that the switch is closed instead of open (since the voltage is low)? Anyway, it should not matter how long the switch stays in the closed position after a strike since I only want to detect if the switch was closed at any time near the detected time of the detected strike by the main piezo. But as I said, maybe I did not fully understand your comment.

[corrados]

Now I did some simple tests with my new ESP32-S3. I finally soldered the pins on the board and could now use a bread-board to do some testing.

I have used the front end as on the Edrumulus homepage, i.e., using two 22k and one 100k resistor.

If I measure the ADC voltage without connecting anything to the 100k resistor, I read a value of 1994
If I now shortcut the 100k with GND (equivalent to switch is closed), I read a value of 1787
If I now use a 10k resistor to GND (as in the Yamaha cymbal), I read a value of 1807

That is interesting since these values would indicate that a simple threshold test would be sufficient. Of course, this is a very simplified model of the pad and if you hit a switch with the stick, it will behave a bit differently than simply connecting components on a bread board. But at last looking simply at the numbers, I think there would be some hope.

[3hhh]

The current edrumulus code just uses the scan time (2,5 to 6ms depending on the pad), which isn't great

This, I don't understand. Do you mean that the switch is closed instead of open (since the voltage is low)? Anyway, it should not matter how long the switch stays in the closed position after a strike since I only want to detect if the switch was closed at any time near the detected time of the detected strike by the main piezo. But as I said, maybe I did not fully understand your comment.

Yes, I meant closed, not open (I fixed it in the original comment). My point was that IIRC currently a threshold is used at which the switch is considered closed. Once it goes back above that threshold the switch is considered open again. However there's quite a large time range afterwards where the voltage will be above that threshold, but still not back to it's original value (all of the values in the diagrams above are different from the original values as I had those removed). And that has an impact on the DC offset, which will be incorrectly adjusted for the rim switch input port. Thus it may have an impact on subsequent trigger computations. Admittedly it's probably a minor issue though as the time where the switch is in the half-closed/open state should be much smaller than the time where it's fully open.

Of course, this is a very simplified model of the pad and if you hit a switch with the stick, it will behave a bit differently than simply connecting components on a bread board. But at last looking simply at the numbers, I think there would be some hope.

Yes, please test with real hardware and drum sticks. My first tests with keeping the rim switches closed for a long time by pressing on them were quite promising as well; then I started hitting them with drum sticks and suddenly I had these switch bounce effects...

[corrados]

And that has an impact on the DC offset, which will be incorrectly adjusted for the rim switch input port.

Yes, it has. But I would think that it is negligible since the time it stays closed is much smaller than the time you hit the next strike and therefore the DC offset estimator corrects for that error soon after it.
The situation is different for the choke function. If you hold the pad for a while, this can significantly influence the DC offset estimation and I already have some code to suppress the DC offset estimator while a choke was detected.

Yes, please test with real hardware and drum sticks.

I will. But this will most likely take some time (again) since another soldering is involved...

What I actually do not understand is that your calculations in Spice showed that the 10k cannot be detected with the ADC if using 22k and 100k resistors. But my measured numbers tell a different story. So some difference between your theoretical calculations and the real system much exist.

[3hhh]

On 12/11/23 18:20, Volker Fischer wrote: What I actually do not understand is that [your calculations in Spice showed that the 10k cannot be detected with the ADC if using 22k and 100k resistors](#89 (comment)). But my measured numbers tell a different story. So some difference between your theoretical calculations and the real system much exist.

Shorting an effective Rs=110k vs Rs=100k to GND with Rp=22k is 13 mV (16 points in a 12 bit ADC / 4 for 10 bit) difference according to my simulation. This looks pretty much in line with your practical results. The link you were referring to was talking about my situation with an effective Rs=131k vs Rs=136k (the input impedance of my pad is 31k-36k), which results in 4mV difference only.

[corrados]

Oh, I see. That makes sense. Thanks for the clarification.

[3hhh]

More samples at #133 (comment) - unfortunately making both approaches questionable.