Category: Projects

The current form of the e-drum array is two adjacent octave groups, requiring 4 rows of drums. The array has a pronounced curve around the performer, requiring each row of drums to have increased space between units.

Four rows of drums require 3 different clamp styles (A, B, and C, shown on the left) to accommodate the expanding width between the drums. In order to make the array neater and more stable, we can also remove unused mount points at the edges of the array to make edge clamps, such as the clamps D, E and J. After assembling the array full array for the first time I felt that the top row of drums in each octave needed more support (they were held at only one point) so I created fill-in clamps H and I to add rigidity.

The clamp set

Row 1
Row 2
Row 3
Row 4

Assembly Plan

Each of the clamp models available on this site has an identification letter somewhere on the part that relates to the assembly diagram above. To assemble the full 24 drum array you will need: 3 A clamps, 4 B clamps, 4 C clamps, 1 D clamp, 1 E clamp, 3 F clamps, 1 G clamp and 1 j clamp.

Putting the Drums Together

When the array begins to take shape it can become difficult to access all of the clamps and nuts, so these instructions are intended to be very general and simply illustrate the required steps. You will need to find your own strategies to complete the whole array.

1. Prepare the rim

Push the 75mm M6 bolts through the rim, ensuring that the hex heads are embedded in the matching rim sockets. Refer to the layout map above and put a nut on every bolt that will need to carry a clamp. This is my ‘C1’ drum, so every side is attached to another drum.

Inset the mesh skin and place the clamps over the top of the nuts.

Insert the shell and fit nuts to all of the bolts. Mesh skins do not require a lot of tension – it is possible at this stage to reach playing tension by compressing the rim and shell with your hand while tightening each nut. The drum trigger is shown mounted in this photo, but they can be slipped into place though the bottom of the drum after assembly as well. This also allows for easy maintenance of the triggers if any become faulty.

Push the clamps firmly against the bottom rim of the shell and secure them by finger-tightening the loose nuts installed in the first step.

You can now tighten the nut from above the clamp (as shown) or from the other side of the lower rim, which may be easier to reach as the array grows and drums are surrounded by their neighbors. Tightening from below the drum with slightly raise the skin tension on that lug. Mesh heads do not need to be tuned, so small variations like this are not detrimental to the drum performance.

Mounting of the array.

All of the clamps have holes designed to accept the top of a small cymbal stand. The setup below uses four cheap stands to support the array, or two to support each octave. This allows the array to be spit into two groups if the whole array is too large. I also prefer to break the array into octaves for storage and transport. You are free to use as many cymbal stands as you wish, but each octave should be independently supported.

Also shown below is a 10″ drum assembled from 3D printed segments.

A ‘C’ clamp attached to a cymbal stand. The ‘C’ row has larger holes that fit my Tama cymbal stands. All other brands that I own work with the smaller holes. It is not necessary to use a cymbal topper, the weight of the array is sufficient to prevent it from moving.

Connecting the drums to the controller will be covered in the post detailing the electrical and software design.

I do appreciate that both of these VR instrument platforms have given some thought to allowing performance data to leave their VR environments, but the implementations are currently rather restrictive and incomplete, especially if you use an Apple computer. I have made or modified some tools that work for my simple needs and might be generally useful. I expect these tools to be rapidly superseded by official tools with greater capabilities. At least, I hope that will be the case.

Patchworld

Patchworld has a suite of internal objects designed to interface with Ableton Live, collected under the ‘Ableton toolkit’ category in the object menu. A range of sliders, toggles, knobs and strange disquieting stretchy interface blobs can be wired to an 8 channel bridge device. This device can send a range of either 0-1 or 1-127 on any of 4 sets of 8 channels. Surprisingly, there is no facility for sending notes or note velocity values, so I made one to use with my drum array.

Information is received by a MAX patch available from maxforlive.com. Although versions 1.0 and 1.5 are available I have yet to find any difference between them, even after opening them in editing mode. The embedded javascript object that is supposed to automatically link the bridge to a running copy of Patchworld has never worked and appears to be missing the code. The bridge will function if you manually enter the IP addresses.

I have addressed the lack of note information by simply sending the MIDI note number and corresponding velocity over two channel pairs previously used for MIDI controllers; 5+6 and 7+8. The remaining 4 channels are still available for MIDI CC. Each bridge can be set one of 4 channels, each with 8 lanes, so the loss of 4 to note values should not be much of an imposition. I originally used only two channels for note transmission but the response time was not fast enough to handle the data generated from two handed playing.

Using the modified Patchworld OSC Bridge

The new sections I have added are:

1. Input Detect. This button flashes when receiving note information through channel 5 or 7.
2. Note Test. Pressing this button will send a copy of the last note received at a velocity of 64. If no notes have been received this button will send note 64 for channel 5 and 66 for channel 7. It can be difficult to use a VR instrument to send notes when mapping MIDI or tuning parameters inside Ableton, even with good pass-through cameras such as those on the Quest 3. My Quest is always very quick to enter sleep mode when lifted away from the face, making it difficult to ‘peep’ at the screen without having to wait for the headset to wake each time. Use these buttons instead of juggling your headset.
3. Test CC in is similar – rather than trying to keep continuous gestural controls engaged in the headset while working inside Ableton, these dials can be used to send the same CC numbers for testing instruments, assignments, etc.

Virtuoso VR

There is a already an official companion application (and a VST3 plugin) that allows Virtuoso to send note and controller information to your computer. Neither of these work on my Mac. Although source code is available, the pre-made executables are Windows platform only and I cannot use them. To address this lack I have made both standalone MAX applications and M4L objects that can connect to a running copy of Virtuoso. They currently only support the harp and marimba instruments, with hand rotation sensing for the marimba (the harp does not send this information for some reason). The standalone application can send MIDI information to whatever port and channel you select. M4L objects have no concept of port or channel (all information is channel 1 no matter what port number you send), so I will, in a future version, allow channel number to be used as a coarse MIDI controller for parameters the do not require fast updating – it may be useful for selecting timbre or physical properties for Collision. This is a work in progress and will be expanded to cover all of the Virtuoso instruments. For instrument builders or tinkerers who have to deal with real-world information flows, Live’s built-in MIDI mapping is still, in 2024, infuriatingly unusable, with no way of directly entering mapping information. To make mapping possible I have taken the MAP buttons from the Patchworld bridge.

Using the Standalone Application and M4L tool

The layout of the two interfaces is nearly identical but some controls have different functions as described below.

1. Each instrument has a circular input detector. This will flash when MIDI notes are received for that instrument.
2. Each instrument has toggles to accept Note Off messages. Note off is not always needed, especially for percussion sounds where it can cause problems by abnormally terminating sounds. Most continuous-note instruments, such as synthesisers, will need to receive note-off messages or the sounds will never stop.
3. Each instrument also has an ‘Accept MIDI Channel’ toggle. In the stand alone application this allows the channel selection tools of the virtual instruments to modify the MIDI transmission channel of the relevant instrument output. M4L has no MIDI channel information, so this will be repurposed into another MIDI controller receiver.
4. The left and right tilt channel indicators, the red arcs, show input data and can also be manipulated with the mouse to send controller information for testing purposes. The percentage boxes underneath can be used to set the lower and upper bounds of the controller mapping transmitted to mapped Live targets.
5. ‘Send local IP’ sends the computer’s IP address to Virtuoso VR via the network.

It isn’t hard to make a DIY e-drum system that ‘sorta’ works, but there is a much longer road to making one that is good to play. The Alesis DM Pro that I have using is the latest of a series of Alesis products that I have used for processing my home-made drum pads. I’ve also owned a DM10, DM5 and a DM4. My very first E-drum unit was an ancient Roland PM16. All of them gave a far superior ‘feel’ to just sticking peizos straight into the Arduino analogue inputs. This direct approach has problems detecting some triggers, strange velocity response and crosstalk (one input setting off other adjacent drums) even when only one drum is plugged in.

We are using roughly the same hardware components, my old Tama Techstar pads were just piezos glued to plywood, so what is going on and how do these commercial products make it work so well? To get a more predictable, stable drum we need to improve our handling of the sensors. Look at the oscilloscope captures below, particularly at the Vmax(1) at the bottom of the images.

• Piezos can damage your Arduino. A piezo, struck hard, can send (depending on the model) 10, 20 or even 30v down a line that would really rather be seeing about 5v. We need to limit the voltage to safe levels.
• Piezos are the wrong impedance for easy sensing. The Arduino wants to measure from a low output impedance (~10KΩ) but it is currently seeing about 1MΩ from the input resistor. We can fix this by adding an active buffer (or putting a lower value resistor across the input, but this will reduce sensitivity).
• Commercial products have gain controls (usually electronic, but the PM16 had tiny potentiometers), velocity curve selection and crosstalk detection. These are software solutions and shall be addressed later.

For the sake of simplicity and getting a system up and running quickly, we can use a unity buffer to protect the Arduino and condition the signal.

Opamp Buffering

A unity amplifier is one of simplest ways to use an opamp – you just connect the output of the chip to the negative input, as shown below. Any voltage coming in will be mirrored to the output.

The LM324 is a quad opamp that can operate at low voltages. Output cannot go higher than V_cc – 1.5V (1.5v lower than the voltage you are using to power the opamp), but that should still be enough for testing. If we run it from the Arduino’s 5v out line we will still have 3.5v of room to play. If everything works out an independent power supply can be arranged at a higher voltage to allow a full 5v output.

The oscilloscope screen pictured on the right shows the voltage from the drum hitting 3.6v and flattening out for the duration of the hit. This behaviour can be used to our advantage.

Is this good enough already?

Experimentation with an 8″ drum showed that a lot of expressive playing happens below 3.5v with the hard voltage limit acting like an audio compressor – hard hits are effectively flattened out to similar velocity values, smoothing out runs and fast rudiments. The Arduino Mega also has the ability to use a range of reference voltages for measuring input on the analogue lines. We can set the Mega to measure against 4.3v (the closest preset available) instead of 5v or supply 3.5v to the input reference pin to get a full velocity range from our sensor. We could also just use a 3.5v Arduino like the ESP32 that expects a maximum of 3.5v input, but in that case we would have to find a 5v source from outside the Arduino to run the opamp. We could also just adjust the velocity range in software but we are still losing precision and my work on the sampling violin showed that after you account for a reasonable noise floor that loss of precision really does matter. The biggest problem I found was sitting down at a drumkit is a very different experience from hitting a drum in front of an oscilloscope; what I thought was a reasonable velocity range in lab testing was nowhere near the velocity achieved in real playing. All of my hits were flattening out on the 3.5v rail, giving a very artificial drum-machine like feel to performance. This is not good enough, it feels lazy to leave it half-baked like this, and I’m going to need a lot more drum inputs than even the Mega can give me so we might as well do the inputs properly while working out the multiplexers than can give me 8 inputs per analogue channel.

Next – full range input and signal multiplexing

This is a build document for a large array of E-Drums I am making to support a VR hyper-instrument project. All of the 3D printed objects, Arduino source code and instrument files will be made available through this website with appropriate copyleft licencing, mostly dependent on the most permissive possible licence of the source materials I am using. The hyper-instrument itself will be covered later in a separate series of posts after the construction of the physical instruments has been completed.

Get a good printer.

After several years of mostly solid performance, I decided to upgrade my 3D printer. My old refurbished Wanhao Duplicator (Sold as Cocoon through Aldi) had seen me through the construction of the Ambsonic dome, but was unable to reliably print ABS or run overnight. Temperature variations would always detach print jobs from the build plate no matter how much glue stick or hairspray I applied. It was also far too slow for the big, dense prints I needed to create drum shells. I needed a cheap, fast, fully enclosed printer.

The Creality K1 has mixed reviews and comes with many warnings from the cognoscenti of Reddit about poor build quality and recurring print issues. I considered myself experienced enough to fix whatever went wrong and bought one at a good discount. It has jammed only once in several months of hard use. It is fully enclosed and reaches temperatures of up to 50°C internally with heat from the build plate alone. This is not always desirable, so leaving the door open when printing PLA in hot weather is a must.

Printing the drums

I found several sets of designs for drum shells on Thingiverse (a site with a huge selection of free-to-use ready-made 3D print designs) and quickly settled on this collection of shells deconstructed for printing on 20cm print beds. The shells and rims are printed in sections and held together with M3 screws. The K1 is just big enough to print the 6″ shells in one piece, taking 6.5 hours in fine mode. The 6″ rim also prints in one piece, taking 2 hours. Shells printed using both ABS and PLA have held tension with skins installed for around a week with no signs of structural problems. Larger rims, such as the 8″ and 10″ sets have distorted (shown below) but are working well enough and are not losing tension.

Making the sensors

E-drums use a type of pressure sensor called a piezo. These are usually sold as flat discs that may have wires already attached. In the type of sensor I am using, force from the drum stick impacting the mesh head is transmitted to the piezo through a cone of soft material. The piezo is sandwiched between the cone and another disc of the same material that insulates the piezo from the frame of the drum. Multi-sensor drums that can detect playing on the rim often mount another peizo directly to the drum frame.

The mounting plates for the internal sensors included with the downloaded files made no sense to me, so I quickly designed a new friction-fit sensor sled that allowed for another jack to be installed underneath the drum, to be used for tight arrangements where the sides of the shell might not be accessible. The sensor is patterned after the Roland cone sensors used on their V-drum products. Although ready-made cones are available from aftermarket manufacturers, they are easy to make from materials available from Bunnings, for a fraction of the price

I experimented with several types of foam when developing the cones, including hybrid cones that used softer material for the top half. It didn’t really matter – every foam I tried gave good results, but a cone with a pointed tip such as the one shown above will need to be constructed from a firm material. Having a small point is especially desirable for drums with a centrally mounted sensor as it makes the foam cone harder to hit directly with the drum stick (which usually results in a very, very loud hit that stands out from regular playing). The sensor sled is a tight friction fit inside the drum but is secured with 20mm M3 bolts to keep it in place when plugging leads into the integrated Cliff jack.

Making the cones

I use a 3D printed cone shaping jig and a reciprocating scroll saw to shape the cones. Firmer foams, such as this EVA, can be shaped with a powered wheel sander. Soft foams have a tendency to grab blades and sanding discs/belts and can be dangerous to work with if you are using high-speed equipment, so I would recommend shaping those materials by hand with a scalpel. The jig is designed to replicate the 66° slope of the original Roland cones.

Assembling the sensor sled.

Bill of Materials

Files (will be linked soon)