Close
0%
0%

Drumidy - electronic midi drum controller

STM32 based midi drum controller with zero latency.

Public Chat
Similar projects worth following
The project is the natural continuation of my mesh drumset project (https://hackaday.io/project/171027-diy-mesh-conversion-of-a-simple-drum-set)
At the moment first version of hardware and firmware has been completed and tested.

In this project I have designed a custom drumset midi controller (currently up to 18 channels) based on small stm32 G431 nucleo board
(https://www.st.com/en/evaluation-tools/nucleo-g431kb.html)
Highlights:
- 9 volume sensitive channels
- 9 dual channels for pedals or pads (common threshold level for pads)
- DIY piezo sensors that can be installed on anything
- 0 latency messages
- typical timing for piezo sensors: 2-3ms peak evaluation and 5us for message to appear on PC
- each channel can be configured to detect rim shots
- debug and configuration via USB serial port

STM32 source code: https://github.com/EvgenyD/Drumidy
PCB's gerber and schematics - in file section.

The midi controller - is a STM32 based system with total 18 inputs sampled at 10kHz rate.

So it is done. Finally manage to put everything together and record small demo. 

Phisical description:

Drumidy main board is a small 60x90mm PCB with a few smd components, 9x stereo jacks, 1 USB port, and place for a STM32 Nucleo G431 board (similar to arduino nano, but faster)

Each stereo jack has two inputs - main (volume sensitive) and auxilary (on/off).

In general, 9 input should cover basic drum set, but to make it more interesting, you could do things like that:

The auxilary channels have optional pull-up resistors. With the resistors disactivated, the channel will be triggered when the level on the input becomes higher certain threshold. To use the channel for a pedal (or button input) you need to activate the pullups.

Electrical description

Source code for the micro: https://github.com/EvgenyD/Drumidy

PCB design and schematics - same link or in the files section.

The system is based on a pretty fast microcontroller in a form of a devboard:

https://www.st.com/en/evaluation-tools/nucleo-g431kb.html

The reason to use it as a devboard is simply to avoid implementing power part on the PCB. As a bonus, it also provides extra USB serial port which I intend to use for debugging and configuration of the drum controller, and drug-and-drop firmware update.

Each channel passes through an opamps (4x4channel opamps). for main channels the opamp provides a buffer (safety measure), for the auxilary channels - opamp sets the threshold for the trigger (1 trimmer to rule them all).

Software part

When plugged into a PC, the board is recognized as a typical Midi device can be used in any software with midi support. 

Personally, I use sforzando with free sound samples SM Drums.

In order to get lower latency on windows PC, I use ASIO2ALL or Magix LowLatency drivers. (the magix's one come with the MusicMaker software but works with sforzando as well)

This combination works "out of the box" and require no adjustment. I only had to adjust volumes for the different voices.

DrumidyCover.zip

STL files for the cover box. now it is all here.

x-zip-compressed - 876.03 kB - 04/04/2021 at 15:56

Download

MainBoard_Gerber.zip

Gerber files of the main board. Initial version.

x-zip-compressed - 59.67 kB - 04/04/2021 at 10:23

Download

SensorSide_Gerber.zip

Gerber files of the small boards installed on the drums. The board's design is too "universal" and should be "optimized". But it works nevertheless.

x-zip-compressed - 10.32 kB - 04/04/2021 at 10:23

Download

Drumidy_V0.2.bin

Fixed config routine. the firmware tested for few months already

octet-stream - 64.63 kB - 04/04/2021 at 10:20

Download

Drumidy_v01.bin

First version of firmware. it uses all pin of STM32G432KB board as inputs (both analog and digital) Pins PA11 and PA12 configured as USB midi output.

octet-stream - 64.52 kB - 02/27/2021 at 16:43

Download

  • Up and running

    Evgeny04/04/2021 at 15:50 0 comments

    So, it seems that all what needed to be done is done.

    On these pages you may find everything used for completing the project. Obviously I don't expect anyone copying the work, but I hope one day it might be of use to someone seeking inspiration.

    I have unplugged my original drum module 2 months ago and have not had any regrets since.

    Regarding future plans, I can forsee at least two.

    1st - get rid of the PC and substitute it with RPi or another STM board. 

    2nd - find alternative to the cymbals, the one I have really bother me.

  • SourceCode online

    Evgeny04/04/2021 at 10:14 0 comments

    It finally happened! I finally learned how to use git. So at this link you can find the sourcecode for the micro.

    I am using this version for few months now and it works flawlessly.

    https://github.com/EvgenyD/Drumidy

View all 2 project logs

  • 1
    Drums and Triggers

    The core of any electronic drumset is correctly implemented sensors. So before starting with complex electronic part, lets first focus on the design of drum pads and signal triggers. 

    1. Physical part.

    The drum pads I use are well described in my original project:

    https://hackaday.io/project/171027-diy-mesh-conversion-of-a-simple-drum-set

    I still have plans to make custom cymbals, but at the moment i'm using pads from my first drumset. 

    2. Piezo sensor

    The sensitive part, or the trigger, are very basic piezo sensors that you can easily find.

    Personally I used 27mm sensors, but the size has no impact on the final result.

    In order to mount on the pads, here are few tips:

    The part that is the most important here is the piece of foam between sensor and the mesh. If you ever checked similar project, all of them use cone foam pieces, lightly touching the skin of the drum. 

    These pieces would work well for acoustic drum as they would not interfere with the sound of the instrument. In case of a mesh head, we dont really need the natural vibrations of the head - the piezo will bluntly read all these vibration and filtering the signal will become a very difficult task.

    But if you put an ugly square piece of foam, it will instantly dumper all the extra peaks leaving a very nice clean signal. Here is signal with foam brick vs cone (not related to current project, we still going to add few tricks):

    UPDATE: After lots of test and sleepless nights, i discovered that THE BEST design for the foam is ugly brick with cutout center:

    that small hole cleans the signal from almost all parasitic oscillation, prevent 'hot spot' in the very center, and generally provides much more consistent response.

    The signal will continue to oscillate as long as there are oscillations exist in the mesh, so less oscillation - less noise.

    Second important point - on the plot above you can notice that the first positive peak is much more evident that negative. But if you by chance mixed up piezo polarity, you will end up with analyzing the part that is below zero.

    3. Electronics (sensor side)

    In order to make the signal microcontroller friendly, here are few components installed on the pads:

    The contacts A and B is where the signal from piezo comes.

    Then the signal passes through the Schottky diode D1 (BAT54J). This diode shifts down the signal by ~0.25V and cuts off all the negative part.

    Then the signal passes through a simple potentiometer (1Mohm) and goes to the microcontroller.

    The trimmer allows to set the general volume of the pad so one can adjust the dynamic range of each single drum.

    Update: Z1 was never installed because apparently at low current it cuts out at much lower voltage (~0.6V)

    (Finally, the 3.3V zanier Z1 (MM3Z3V3C) diode will prevent the signal to go over the safe level.)

    So, the output of the system looks like this (this is what mcu sees and what we have to analyze):

    The two peaks are 70ms apart and you can see that the signal in between is nice and pretty. There is still small after-peak noise, but that can be clean up by the controller. On that later.

  • 2
    Connecting cymbals

    So far I could not come up with a better solution then the stock Alesis cymbals, so I kept them.

    There two problems though.

    1. Apparently the piezos inside the cymbals are mounted upside down. This leads to ~10ms delay on the signal (its positive part) and to a lot of post-peak oscillations.

    2. the negative part of the signal needs to be removed. 

    For the moment, my solution is the custom cables (6.3-3>.5mm jacks) with diodes inside and extra 3.5 sockets for aux input signal:

    Wiring:

    The mono input of the 6.3 jack is flipped and connected through the diode (to cut off negative part of the signal) to the main line of the cable (tip line, L signal).

    Extra 3.5 mono jack is wired directly to the second channel (1st ring line, R signal) of the cable. this signal is filtered with 0.1uF cap to avoid "cross talking".

    The internal resistors of the cymbal provide acceptable level, so no extra trimmer is required.

  • 3
    Setting up input channel.

    The USB port of the Nucleo is set to be used for showing debug information in real time and configuring the channels.

    when connected, the board sends peak information on every hit:

    Two main parameters are peak height (ADC value like 1666/4096) and peak's duration (number of points, t=41, corresponds to 4.1ms).

    Each channel has following parameters, all adjustable via serial port:

    1. Main Voice - midi code to send when event detected. e.g. snare - 26
    2. Alt voice - midi code to send when event detected and special condition met, like pedal pressed of rim hit detected.
    3. Aux voice - midi code to send when event happens on auxiliary input
    4. Min time - shortest peak length to consider, helps removing noise.
    5. Max time - longest peak to consider. Helps removing events like pressing drum with hand.
    6. Volume - in % to 4096. when set to 50, then volume 100 correspond to adc reading 2048. (25->1024, 12->500 etc)
    7. Threshold - the minimum peak height to consider.
    8. Input type.

    The last one defines behavior of the channel. at the moment following combinations are implemented and tested (some more than others):

    MESH_PAD_AUTOAUX = 0,   // normal pad, independent auto aux
    MESH_RIM_AUTOAUX = 1,    // normal pad with rim detection, independent auto aux
    CYMBAL_AUTOAUX = 2,      // cymbal input (faster peaks), independent auto aux
    CYMBAL_HIHAT = 3,            // hihat input, aux - pedal
    CYMBAL_2_ZONE = 4,        // cymbal input, aux - blocking pad
    CYMBAL_MUTE = 5,           // cymbal input with muting pedal (button) 

    auto aux - means that at the startup the board selects type based on the input's level - low - pad, high - pedal

    Peak time depends mainly on the mesh tension and can vary in very wide range. e.g. cymbals peaks are in a range of 0.5-2ms and the tuned head is about 3-6ms. 

    in fact, if the channel is configured as "mesh with rim", the rim hit results in a much shorted time and the MCU sends different voice. If rim is not activated, the rim hit is simply filtered out.

    All main parameters are configured through serial port and the process look like this. in order to skip any parametes, it is enough to send some non-numerical char (e.g. "+") 

    If someone ever reach this point, let me know, I might write more details on configuration.

View all 5 instructions

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates