corrados / edrumulus Goto Github PK

If the hihat pedal is used, the outcome is usually not just a pedal MIDI note, but a regular medium velocity hihat note or even hihat rim note as well. This is obviously caused by the hihat cymbals moving during the stomp. The resulting notes should be suppressed. Using the cross talk setting on the hihat helps, but isn't great as the hihat is only meant to be suppressed in that particular case and not when played together with other instruments.

Related: #109

The Millenium MPS750x snare has its piezo at the top of the pad.

This has the advantage of a reduced hot spot effect, but doesn't work so well with edrumulus pos sensing, which currently assumes the piezo to be located in the middle of the pad.

It would be nice to support pads with piezos at the top.

I believe a simple version might be possible by translating the current pos sensing as follows:
middle --> edge
edge --> edge
everything else (somewhere in between) --> middle / reduce distance to edge by 50%

I'll test that once I have some time.

edrumulus_parameters.cpp currently has no way of setting the spike cancellation parameter.

According to

(I want to permanently set it to 2 for one of my pads.)

My set has a lot of cross talk and setting all cross talk values of all pads to 31 still doesn't fix it.

I even set the cancellation time to 100ms, but I still observed cross talk on e.g. hard snare rim shots.

Imho the issue probably lies with the algorithm:
If I understand it correctly, it simply checks whether there were higher spikes in the past. However I observed in practice that cross talk spikes may actually arrive before the spike of the pad I actually hit. This is not taken into account by the current algorithm. Of course that would involve holding back the Midi output, which in effect introduces a latency.

OS: Win10
Python: 3.10
Shell: Git bash
Controller: ESP32

After following the manual and installing Python packages I tried running edrumulus_gui.py using:

tools/edrumulus_gui.py rtmidi

which results in:

/usr/bin/env: ‘python3’: No such file or directory

I would suggest using this in the docs instead:

python tools/edrumulus_gui.py rtmidi

but it results in:

Redirection is not supported.

Any idea?

Using the cymbal choke currently causes low volume rim triggers (usually two or so).

Also, holding the choke sometimes seems to just delay playback rather than stopping it. The latter may be a drumgizmo issue though.

Is it ok to add https://www.youtube.com/watch?v=YWE1LgwQbbQ to the readme, if so, I'll open a PR for it.

When I run the edrumuluscontrol I always have to check the code what table is midi in, and which one is midi out. Would be very useful (also to new users) to have these tables labeled like you did with 'Edrumulus settings'. I tried looking into adding it myself but this programming language (matlab?) is very foreign to me.

The input and thus the midi signals generally start to float on ports without drums connected.
Obviously that's not great for testing, broken parts, performances, ...

The available solutions I'm currently aware of:

1. Use a simple pull-down resistor.
   Apparently there's some debate about whether this is advisable for analog inputs (e.g. here), but I guess I'll give it a try sooner or later.
2. Use e.g. cinch connectors with 3 pins where the third pin can be used to deactivate the input circuit ("off switch").
3. Fix it in software by detecting floating input signals and not generate midi output in that case.

Since the second option is not backwards compatible and also doesn't work with the Roland cable, I only consider the other two options viable at the moment.

I just wanted to use pin A17 on a Teensy 4.1 and it didn't work.

I think the reason is that analogRead(17) reads pin 17, which is A3. Teensy forums suggest to use analogRead(A17) instead, but putting A17 as pin for edrumulus didn't work neither. Possibly A17 is defined by some non-Teensy include, I don't know.

According to the Teensy forums this behaviour applies to all pins >= 14. Maybe it even applies to all Arduino boards?

https://forum.pjrc.com/threads/64046-Cannot-find-A14-A17-on-a-Teensy-4-1
https://forum.pjrc.com/threads/54963-trouble-reading-Analog-pins-A14-and-above

1. Use a pad with pad_settings.rim_shot_is_used = true; and possibly pad_settings.rim_use_low_freq_bp = false;.
2. Notice that everything works as intended.
3. Physically disconnect the rimshot input cable.
4. Notice that regular hits on the pad play the rimshot Midi note instead of the regular Midi note.

This may be a programming mistake or an instance of #91 on the rimshot input, idk.

Currently BOARD_LED_PIN is defined in edrumulus_hardware.h. Since my ESP32 doesn't have a builtin LED, I need to change it to a different GPIO nr. Ideally I wouldn't want to touch anything in edrumulus source except for the .ino file so my request is to move or add support for defining the BOARD_LED_PIN in the .ino instead, leaving edrumulus source untouched.

In this method, there are a few prototype boards listed. I hand soldered the Prototype 2 circuit, so I'm really hoping I don't need to solder the newer iterations.

If pin 5 is not set to low, then the code defaults to prototype 4. If I am using the prototype 2 front end circuit, will the pin values and default settings for the prototype 4 board still work correctly? If so, could this be reflected in a comment in the code? If not, could prototype 2's PDF be removed, or a disclaimer added?

// -----------------------------------------------------------------------------
// ESP32 Dual Core -------------------------------------------------------------
// -----------------------------------------------------------------------------
#ifdef ESP_PLATFORM

int Edrumulus_hardware::get_prototype_pins ( int** analog_pins,
                                             int** analog_pins_rimshot,
                                             int*  number_pins,
                                             int*  status_LED_pin )
{
#ifdef CONFIG_IDF_TARGET_ESP32
  // Definition:
  // - Pin 5 is "input enabled, pull-up resistor" -> if read value is 1, we know that we have a
  //   legacy or custom board. Boards which support the identification set this pin to low.
  // - Pin 18, 19, 22, 23 define a 4 bit sequence which identifies the prototype hardware.
  // NOTE: avoid ESP32 GPIO 25/26 for piezo inputs since they are DAC pins which cause an incorrect DC offset
  //       estimation and DC offset drift which makes the spike cancellation algorithm not working correctly
  pinMode ( 5, INPUT );

  // check support of protoype board identification
  if ( digitalRead ( 5 ) == 0 )
  {
    // read the identification bit field and check the states
    pinMode ( 18, INPUT ); const int bit1 = digitalRead ( 18 );
    pinMode ( 19, INPUT ); const int bit2 = digitalRead ( 19 );
    pinMode ( 22, INPUT ); const int bit3 = digitalRead ( 22 );
    pinMode ( 23, INPUT ); const int bit4 = digitalRead ( 23 );

    if ( ( bit1 == 0 ) && ( bit2 == 0 ) && ( bit3 == 0 ) && ( bit4 == 0 ) )
    {
      // Prototype 5: 0, 0, 0, 0 -----------------------------------------------
      // analog pins setup:               snare | kick | hi-hat | hi-hat-ctrl | crash | tom1 | ride | tom2 | tom3      
      static int analog_pins5[]         = { 12,     2,     33,        4,         34,     15,    35,    27,    32 };
      static int analog_pins_rimshot5[] = { 14,    -1,     26,       -1,         36,     13,    25,    -1,    -1 };
      *analog_pins         = analog_pins5;
      *analog_pins_rimshot = analog_pins_rimshot5;
      *number_pins         = sizeof ( analog_pins5 ) / sizeof ( int );
      *status_LED_pin      = 21; // LED is connected to IO21 on prototype 5
      return 5;
    }
    else if ( ( bit1 > 0 ) && ( bit2 == 0 ) && ( bit3 == 0 ) && ( bit4 == 0 ) )
    {
      // Prototype 6: 1, 0, 0, 0 -----------------------------------------------
      // analog pins setup:               snare | kick | hi-hat | hi-hat-ctrl | crash | tom1 | ride | tom2 | tom3      
      static int analog_pins6[]         = { 36,    33,     32,       25,         34,     39,    27,    12,    15 };
      static int analog_pins_rimshot6[] = { 35,    -1,     26,       -1,         14,     -1,    13,    -1,    -1 };
      *analog_pins         = analog_pins6;
      *analog_pins_rimshot = analog_pins_rimshot6;
      *number_pins         = sizeof ( analog_pins6 ) / sizeof ( int );
      *status_LED_pin      = BOARD_LED_PIN;
      return 6;
    }
  }

  // if no GPIO prototype identification is available, we assume it is Prototype 4
  // analog pins setup:               snare | kick | hi-hat | hi-hat-ctrl | crash | tom1 | ride | tom2 | tom3  
  static int analog_pins4[]         = { 36,    33,     32,       25,         34,     39,    27,    12,    15 };
  static int analog_pins_rimshot4[] = { 35,    -1,     26,       -1,         14,     -1,    13,    -1,    -1 };
  *analog_pins         = analog_pins4;
  *analog_pins_rimshot = analog_pins_rimshot4;
  *number_pins         = sizeof ( analog_pins4 ) / sizeof ( int );
  *status_LED_pin      = BOARD_LED_PIN;
  return 4;
#else // CONFIG_IDF_TARGET_ESP32S3
  // analog pins setup:                 snare | kick | hi-hat | hi-hat-ctrl | crash | tom1 | ride | tom2 | tom3  
  static int analog_pins_s3[]         = {  4,     6,      7,        9,         10,     12,    13,    15,    16 };
  static int analog_pins_rimshot_s3[] = {  5,    -1,      8,       -1,         11,     -1,    14,    -1,    -1 };
  *analog_pins         = analog_pins_s3;
  *analog_pins_rimshot = analog_pins_rimshot_s3;
  *number_pins         = sizeof ( analog_pins_s3 ) / sizeof ( int );
  *status_LED_pin      = BOARD_LED_PIN;
  return 4;
#endif
}

As already discussed, I'm pretty sure that the analog circuit is not optimal and likely doesn't work for everyone.
E.g. for me the proposed 22k voltage divider produced a rather bad SNR leading to many other issues.

The differences mostly come from the unknown Piezo output voltage range, which may be +- 0,1-10V.
The effective voltage range depends on:

• piezo hardware (size, thickness)
• trigger cushion foam (i.e. the maximum velocity at which a user can possibly hit the piezo)

In my particular case the voltage range of the piezo seems to be around +-1V and rarely more. This can be measured rather easily by plugging the piezo to the line in which runs at +-1V range. If there's no clipping, then you're apparently in that range.

I played a bit with the apparent industry-standard software LTSpice to find a set of parameters that may work for me and interestingly found quite a different one from the proposed parameters.

Here's a comparison of the parameters proposed by edrumulus and the seemingly better ones for my case (+-1V, 2kHz spikes):


simulation (needs to be renamed to edrumulus.asc)
(The C3=1p case is roughly identical to what edrumulus does = no capacitor.)

One can see that the voltage range in the edrumulus example is ~0,3V, whereas it could be ~2V as in the second example. Of course that also affects the SNR.

Therefore imho it would be more honest to tell people that they need to play with the parameters to find a circuit that may work for them.

Disclaimer: I still need to validate the simulation in practice.

To reproduce:

1. Start edrumulus_gui.py.
2. E.g. remove the Teensy controller from USB to make it hang (this may be a separate bug of its own).
3. Kill edrumulus_gui.py
4. Notice that the trigger_setting.txt is 0 bytes.

It would be useful for people using edrumulus in their project to be able to display/determine a version for Edrumulus. For my first prototype, if I add a display, this would be the first thing I want to see when the device is on.

hi, I'd like to give this a try but is this disclaimer still up to date or are there changes to the diagram?

My MPS750x ride generates a rim piezo signal that is very strong. Setting the rim boost to 0 and the rim threshold to 31 still produces bad results (too many rim triggers).
It would therefore be good to have higher threshold or negative rim boost available.

Alternatively I could of course dampen the signal in hardware, but imho having a strong signal available shouldn't be a disadvantage.

By the way that's how one might distinguish bell, bow & rim on that ride: If the rim signal is weak (currently rim boost 0, rim threshold 31), it's probably the bell, if it's mediocre, it's the bow, otherwise the rim.
Possibly Millenium still does it differently though.

The hihat stomp output was rather weak during my tests compared to the hihat hits.

This could be fixed by postprocessing it with a mixer; however edrumulus currently uses the same Midi note for a stomp as for a hit on the hihat.

Imho it would be better to use different notes, so that such volume issues can be fixed during postprocessing.
Also, stomping sounds slightly different from hitting a hihat in practice, i.e. one might want to use different samples anyway.

I noticed that the cymbal rim dynamics are generally bad - there's just one or two velocity levels even though I have rim boost set to zero.

This may be related to my experiments in #126, but I doubt that as the cymbal piezo value should be taken for the MIDI velocity and not the rim switch value.