Unsupported hardware

[3hhh]

Hi again @corrados,

I was wondering how one adds support for currently unsupported hardware to edrumulus?

If I see it correctly, you usually measure some input signal from the hardware (how's that done? any hardware required?) and then feed it into your Octave model to enable quick testing for the required parameters?

Maybe I'll give it a shot, if my Millenium mod works somehow (yet tbd).

Thanks again in advance for your answer!

[corrados]

The way I am doing it is:

• attach the pad to a normal sound card and record the strikes with 8 kHz sampling rate and according to https://github.com/corrados/edrumulus/blob/main/doc/algorithm.md#test-signals
• add the recording to https://github.com/corrados/edrumulus/tree/main/algorithm/signals
• I create a new type in https://github.com/corrados/edrumulus/blob/main/algorithm/signalsandsettings.m and use an initial parameter set from a similar pad as a starting point
• I then call the script signalsandsettings.m in Octave which automatically uses the script drumtrigger.m
• I adjust the parameters so that the decay curve looks ok and try to get as little false triggers as possible
• then these parameters can be used in https://github.com/corrados/edrumulus/blob/main/edrumulus_parameters.cpp
• to get it fully working, the new type has to be added at multiple places, e.g. in the GUI python script, too

[3hhh]

https://github.com/corrados/edrumulus/blob/main/doc/algorithm.md#test-signals

I guess the process is somehwat different for kicks, cymbals and Hihats, but I guess I get the idea, thanks!

[corrados]

Your modified Millenium drum pad will be very similar to the PD-120 or PD-80R (PD-85). Therefore, I would start using one of these. Maybe it is not necessary to create a new type. Just play with the trigger settings and see if that already works fine for you.

[3hhh]

@corrados Would you mind explaining the available parameters a bit more than in the cpp file?
I'd like to add support for my Pads and Cymbals... So I guess I need to learn it. I do have some understanding of DSP, but it's been a while that I needed it...

In particular I played around with the decay curve a bit, noticed that it's always linear in the Octave model (I guess cymbals cannot be handled by the model?) and noticed that only the second decay appears to have any impact in the model. What are the others for then?

Is mask time the time for which any triggering is prevented after a peak is detected?

I also guess that the hot spot attenuation (whatever that is, idk) currently only exists in the model, but not in the cpp code?

Btw this is how my first 5 hits look like as interpreted by the default pad (I just applied a 20 db threshold instead of 17db):

[corrados]

In particular I played around with the decay curve a bit, noticed that it's always linear in the Octave model (I guess cymbals cannot be handled by the model?) and noticed that only the second decay appears to have any impact in the model. What are the others for then?

The decay curve can have up to three segments. But most pads only use one segment (mostly the middle segment). Each segment defines a length and a gradient. If the length is set to 0, the segment is disabled.

Three segments are only needed in very special cases like the VH12 where we have to suppress ringing of the two halves of the pad in case it is half open. You can see this ringing in the following plot:

Is mask time the time for which any triggering is prevented after a peak is detected?

Yes, it is.

I also guess that the hot spot attenuation (whatever that is, idk) currently only exists in the model, but not in the cpp code?

Yes, hot spot detection never worked correctly.

You can create your own pad type but as I mentioned above, I think the PD-120 pad type should work pretty good for your pad, too.

[3hhh]

Thanks once again!

Here are my preliminary results:

It doesn't look too bad I guess, but two things strike me:

1. The velocity goes high really quick. I had noticed edrumulus to almost only trigger high velocity hits when I tested it without any modifications.
2. At low velocity positional sensing doesn't seem to work too well.

Are there any parameters to fix those two issues?

Also, what's to respect with regards to the press rolls?
Are these only to estimate the mask time?

[3hhh]

I was referring to the many dark blue dots on my diagram above.

To see the rim piezo channel, you have to create a stereo wave file where one channel is the mesh head piezo and the other contains the rim sensor (as far as I remember, the rim channel is on the right stereo channel).

Ok I didn't record the second channel. That should explain why I'm not seeing any rim shots being detected...

However since I don't have leftover I/O ports for stereo signals anyway, I guess I'll only enable rim shots on the snare. I'll look into the snare signal next then.

[3hhh]

The results for the snare look very promising. In particular the dynamics and pos sensing looks a lot better than with the tom. :-)

Unsurprisingly I didn't have to modify the parameters - it's pretty much the same piece of hardware after all.

I think the difference wrt dynamics & pos sensing comes from the piezo foam which is pretty much the only different part than with the tom. The snare foam is much softer than the one of the tom. Maybe I'll try replacing the foam on the toms and have another look at the results (EDIT: Tried that and the signals unfortunately don't look much better. Maybe the Piezo is simply too close to the mesh head to provide really good results, idk).

Rim shots look pretty bad according to the diagram, but I think you already mentioned in your doc that the algorithm isn't too great.

I haven't tested in reality yet...

[corrados]

Please write a feedback how good the rim shots perform when you try it in your real system.

[3hhh]

Hm I tested Tom and Snare against an edrumulus prototype 2 with a Teensy 4.1 on the command-line UI and unfortunately the results are pretty bad atm:

• Both require a velocity threshold of around 20 to not get constant noise signals (velocity 1 and sometimes even higher signals constantly scrolling down the screen).
• The velocity sensitivity then needs to be raised to 15 for the tom to get any reasonable dynamics. Even the maximum of 31 doesn't produce any reasonable dynamics for the snare. Soft hits aren't detected on either.
• Pos sensing is all over the place for the tom. For the snare there seems to be some rate of accuracy, but it's still only 70% or so. In particular hitting the upper edge usually results in a middle detection.
• I haven't tested rim shots.

In total the model doesn't seem to live up to its expectations in practice. :-(

[corrados]

Both require a velocity threshold of around 20 to not get constant noise signals (velocity 1 and sometimes even higher signals constantly scrolling down the screen).

I don't have a Teensy 4.1 available, only a Teensy 4.0. To my impression, the Teensy 4.0 has less issues with noise compared to the ESP32 board. For the ESP32 board, sometimes the USB power supply was responsible for a lot of noise. You could try to use a powered USB hub. Also you could try to use a different USB port on your PC. I hope that the voltage converter on the Teensy 4.1 is not worse than the one on the Teensy 4.0.

What you also can do is to try to mitigate the impulse noise in software by using the a "spike" value of 4 in the Edrumulus command line GUI.

The velocity sensitivity then needs to be raised to 15 for the tom to get any reasonable dynamics. Even the maximum of 31 doesn't produce any reasonable dynamics for the snare. Soft hits aren't detected on either.

As you can see in the edrumulus_paramters.cpp file, my velocity_sensitivity values are all pretty small. I have never needed such high values. Please check your schematics once more. Maybe the diodes are in reversed direction or a connection on the board is incorrect.

Pos sensing is all over the place for the tom. For the snare there seems to be some rate of accuracy, but it's still only 70% or so. In particular hitting the upper edge usually results in a middle detection.

What is the hardware difference between your tom and snare pads? Have you modified both of them? If you have only modified the snare pad but the tom pad has its head sensor still close to the rim, positional sensing will not work the same as with center mounted piezo sensors. On the PDX-8 I had some positional sensing working but it was much worse than on center mounted piezos.

[3hhh]

You could try to use a powered USB hub.

You were right about the powered hub. That just enabled me to lower the threshold to 12 (vs 20 before) and receive at least some soft hits on the snare. However I also had to modify other parameters to rather absurd values (mask time = 0, spike = 2), which leads me to the conclusion that the model is way different from reality.

Is it possible to receive the original signal directly from the Teensy?
I tried to use this code, but without success.

I'm pretty sure my original recording for the model had some software interpolations in between.

What is the hardware difference between your tom and snare pads? Have you modified both of them?

Yes, I modified both. The main difference is that the piezo position of the snare is lower than that of the tom (by 2-3mm or so). Also, the snare piezo has more and softer trigger cushion foam on top of it than the tom.
I'll try replacing the foam by more professional one...

[3hhh]

I'll test whether I get good results with the 10M resistors and otherwise either remove the Millenium circuit or give up...

Results are okayish wrt velocity, bad wrt pos sensing. Removing the Millenium circuit doesn't seem to change the incoming signal.

[corrados]

That's interesting. So, it seems that there is more than just the requirement of a center head-mounted piezo to get a good positional sensing performance. thijstriemstra has a Drum-tec Diabolo which is supposed to have positional sensing support but the positional sensing performance in Edrumulus was never good as you can read in this thread. Maybe the type of mesh-head has also an influence on the positional sensing.

Unfortunately, I did not have a Drum-tec Diabolo pad myself but I asked in the official Drum-tec Facebook group and they confirmed that positional sensing works fine with the Roland modules. There are just a few Youtube videos about this pad and they even show a bit of positional sensing but it is hard to judge if the positional sensing performance is really as good as with original Roland mesh-head pads. Judging from the Youtube videos, I think some positional sensing works but the performance is not really good. It seems for the Diabolo pad and a Roland module, the positional sensing does not have a nice transition from edge to middle. It seems to jump from one state to the other.

Would be interesting to see if eDRUMin performs better with these pad with regard to positional sensing.

[3hhh]

Well, the pos sensing in the model looks relatively fine. In reality however I tend to get relatively reliable middle sensing and bad edge sensing (at the right edge, it jumps to 100% middle or 100% right edge, somewhere in between it's usually 100% middle; at the top edge it's pretty reliably always 100% middle).

I'd like to use the signalsandsettings.m model on a real signal, but currently I don't understand the model well enough to adapt it to real signals.

[3hhh]

New findings wrt resistor values: #93

Also, I noticed that soldering female 6,3mm jack connectors are apparently a bad choice for edrumulus. Using male-male 6,3mm cables, cutting off one end and soldering male-male jumper cables to the ends appears to be better (less noise, no issues with touching the cables etc.).

[AlienDiva]

Good to know, I've ordered a roll of wide.copper tape for my build just in case. Everything is an antenna.

[3hhh]

So I finally made it to the cymbals of my MPS 750x set.

Unfortunately it looks like I hit into another road block:
The ride is a 3-zone cymbal, the crash a 2-zone, both with only a single stereo 6,3inch output. A 5-hit bow, bell, edge line-in sample of the ride looks like this:

So it has three modes, but looks like mono? I guessed it is a rim switch and configured it that way, but unfortunately edrumulus doesn't recognize the edge. Do you happen to have any ideas @corrados ?

To me it looks like there's some low amplitude signal encoded in at least one or maybe both channels.

[3hhh]

The Yamaha circuit connects 5V to the ring, which indicates that the author believes the Roland & Yamaha cymbals to be powered. This is very different from the edrumulus circuit. Do you power your Roland cymbals / what circuit do you use?

[corrados]

I use the same schematic for the rim switch as for the piezo. Since I use a DC coupling (no serial capacitor), the rim switch does short cut the input and this modifies the measured voltage just a tiny bit. But this tiny bit is sufficient for good detection results.

[3hhh]

I see.

Anyway the MSP 750x cymbals look like they don't use switches.

By now I believe it's a simple differential signal with rim = |T - R| and bow = |S - T|. Probably bell = |S - R|, but I haven't verified that yet. The drum computer probably just checks which of the three signals rings and plays the respective note.

I think edrumulus doesn't support that, does it? It just checks whether the rim piezo reaches a threshold and plays the rim sound then, doesn't it?

[corrados]

Yes, exactly.

[3hhh]

After further investigation it seems that the bell works differently (maybe a switch, idk).

I guess using the prototype 2 circuit with T as GND should get at least the rim going as the bow signal also works for bell & rim (it always plays).

[3hhh]

@corrados
How can I measure the hihat controller?
Its resistance doesn't change on hihat movements according to my multimeter. I noticed that the Millenium drum module seems to power the stereo jack input with 5V and 2,5V.
So it's some sort of active sensor?

Btw crash & ride are powered with 3V3 as well.

[corrados]

On Roland hihat controllers, it's simply a potentiometer. I have no idea what it is in your Millenium controller.