The Arduino has a fixed number of input pins that can be used to measure the outside world. The Mega that I have been using is unusual in having a luxurious 16 inputs available (5 is more common). Unfortunately that is still not enough and the Mega has another problem that is the real deal-breaker – it cannot act as a USB-HID (HID: Human Interface Device) peripheral. USB-HID peripherals such as keyboards, mice, and game controllers are designed for human interaction with computers. They use a standardized protocol that allows for plug-and-play functionality, meaning the device can be recognized and used by the computer without needing additional drivers in most cases.

MIDI from Non-HID Arduinos

The Mega has a USB port that it uses for loading programs and communicating with your computer via a USB-serial connection. This USB-serial can be turned into MIDI by a program called ‘Hairless MIDI‘. The image on the right shows a Bluetooth connected Arduino powered instrument (my nichrome strung Arduino violin), connected to the MacOS MIDI bus. For the Tonnetz drums project, each octave has an independent MIDI controller. I need to some way of merging the MIDI streams from the drum octaves, which is not possible with Hairless (only one copy of Hairless can be running and each copy only accepts one serial input).

I would also like to connect the drums to other MIDI devices, such as iPads, where Hairless MIDI is not available. I decided to retire my Mega in favour of a slower, less capable, Arduino with a special feature – the Leonardo. The Leonardo can become a USB-HID device, one that MacOS (and others) will accept as a USB MIDI interface, just like plugging in a MIDI keyboard. I decided to split the drumset processing in to two octaves with a Leonardo for each. This design will make it easier to use a cut-down 1 octave system when space is tight, make the wiring more compact by putting each controller with its own octave, and reduce the processing load on each Arduino (in comparison with handling the whole array in the Mega using a multiplexer).

The Leonardo has another trick that makes it very suitable for handling an octave of drums. It appears, from the silkscreened pin descriptors on top that is has 6 analog input channels; A0 – A5. If you turn the Arduino over and read the back, digital pins 4, 6, 8, 9, 10, and 12 double as analog inputs A6, A8, A9, A10, A11, and A7 (in that order). 12 inputs, just what I needed. My own Leonardo is a cheap clone from Jaycar without the underside labels, so I have to look at pictures of genuine ones to see the extra pin assignments.

Electrical treatment

The Buffer

We have seen in an earlier post, that piezos can generate voltages high enough to potentially damage Arduinos. This is less likely when the triggers are mounted in the drums (on measurement, voltages are considerably lower), but it is still prudent to protect the central controller for the system. To present a better signal to the Arduino, I decided to buffer all of inputs with inexpensive quad opamps (in this case, the LM324 operational amplifier). These amplifiers are set up for ‘unity’ gain – they simply present to the output what they see at the input, with three important changes. Firstly, the output impedance is much lower (better for the Arduino for technical reasons) and the output voltage cannot exceed 1.5V less than the power supply for the amplifier chip itself. By supplying the opamp with 7.5 Volts, the signal can never exceed 5V. Lastly, in the configuration used below, the opamp cannot amplify a negative signal, protecting the Arduino from ‘ringing’, a negative voltage sent by the piezo as it recovers from the transient of the initial strike. When testing candidates for trigger elements, I have seen ringing voltages approach -3V.

On the right is the buffer layout I hand-wired on prototyping board. Manual wiring like this can be time consuming and error prone but is useful for prototyping as it requires minimal materials and, in comparison to ordering a custom printed circuit board, it is far easier to fix small mistakes.

The Whole Controller Module

This is not the way I would recommend this system be implemented now that the design has been tested and shown to work. A sensible approach would be to develop a single PCB to hold the buffers and the other input conditioning, saving hours of wiring work. It is, however, an implementation that can be attempted for very low cost, without specialty PCB designing software.

A more advanced designer might also use a bare microcontroller instead of an Arduinio, saving more time and money. Unfortunately I have neither time nor money to spare. I have to keep the system modular and, where possible, made from parts I already have available. The Arduino, buffers or input board from this project might be re-used in several more projects and so must remain discrete, modifiable, and accessible.

Two DC-DC voltage converters (the blue modules) power the project. The large converter with the digital display supplies power to the opamp module – the display allows for rapid adjustment on-the-fly without a multimeter. This is desirable because the opamp voltage effectively sets the upper voltage limit, and hence the maximum MIDI velocity, that can be processed by the controller. The smaller module can power the Arduino. This is intended to allow the controllers to operate without a computer attached, sending MIDI via a 5-pin jack mounted on a MIDI shield. The Leonardos are currently powered via the USB connection that sends MIDI to the computer, so these DC-DC modules are not wired in. The required voltages are regulated down from a 9V plug pack.

The 3D printing file for the controller base and the MIDI transmission software for the Leonardo are available from the project download page.

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.

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.

1. Bad piezos. They are the cheapest of the cheap .. but the distribution of failures does not seem to support this. My triggers were working, then most of them were not. That suggests a problem with my manufacturing process. Also, I would be shocked to find that the expensive and the cheap piezos were actually coming from different factories, not just identical units priced for their destination market.

2. The sensors are flexing too much, damaging the piezo material. I have never been able to experience a real trigger from a commercial product because I am too poor to waste money buying one – everything I’m doing is experimentation and guesswork. I don’t know exactly what stiffness of foam is used above and below the sensor and it is possible that the hard foam cones are transmitting too much force to the disc or not supporting them properly underneath. I do have some early sensors I made with soft foam that are working very well, but they are fitted to 10” drums where I used the soft foam to compensate for the large travel of the mesh ‘skin’. I switched to using hard foam because the soft foam was impossible to shape with power tools and did not respond to a hot wire cutter.

3. The adhesive on the foam sheeting is too strong and is damaging the sensors. It is impossible to open up any of my failed sensor packages – the adhesive tears the packaged piezo off the baseplate, leading me to think that the adhesive might be doing the same during assembly or when in use. Commercial products use 3M adhesive sheets that seem just as powerful, but if they are attached to softer foam this might not be a problem. I have also seen instructional videos where the foam cones on Roland drums were changed and it is possible to remove those without destroying the underlying piezo. This one seems plausible.

4. I purchase piezo elements with leads already soldered on. The solder joints are sufficient, but have huge solder balls. It is possible that the strong adhesive is attaching itself to the piezo around the solder balls when I press the stacks together, then damaging the attachment point when I let go (or when hit during normal operation). Official and third-party replacement cones have little channels cut in the cone to accommodate the lead attachment points but I have not been very consistent with my hand-cutting of the relief channels in my own cones (foam with strong adhesive attached is hard to cut reliably with anything. Even scalpels are fouled by the adhesive).

These effects are linked by the physical properties of the system and may affect the outcome collectively or independently.

Now I can try some experiments to see if I can pinpoint what is going wrong. I can’t do any forensics on the assembled triggers as they cannot be taken apart without destroying them. There are, however, a few things I can try at the design phase to sort out what the problem is.

Trigger Assembly and Testing

Make the foam cone from softer materials.

This could help with:

• Flex or shock damage by reducing the forces on the piezo transmitted from impacts on the drum head.
• Possible adhesive damage – the soft foam is not held well by adhesives so it is unlikely to damage the piezo by pulling it apart.
• Possible damage to the solder attachments or surrounding material – the soft foam will not exert a high degree of force around the sensitive areas.

This sensor works – I’m not surprised, I’ve built them before, but I have not directly compared them to sensors made with hard foam. I was not expecting the voltage peak to be this low. This may be from the reduced travel of the 6″ drum skin in comparison to the 10″ I have been using with these softer cones. It may be worth trying to source another foam that has a hardness somewhere between the two I am already using. This foam also has a lot of trouble staying attached to the adhesive on the top of the piezo. In the 10″ shell these soft cones eventually detach from the tape and ‘walk’ out of the drum as they are hit. This is not the design I need.

Reduce the flexing of the piezo

This could help with:

• Possible damage from the cone adhesive when the piezo moves
• Damage to the piezo from flexing with impacts

I have designed a new sensor base that replaces the bottom 6mm of foam (the layer directly under the sensor) with solid plastic. The piezo will mount instead to a length of 2mm think double sided foam tape. I expect that this will drastically increase cross-talk by reducing the isolation from neighbouring pad vibrations, but that can be addressed in software.

This sensor package is working well, delivering good voltages when installed in a 6″ drum. Curiously, although it supplies an almost identical peak voltage to the normal sensor with a foam base, the oscilloscope trace shows a very flat recovery from the drum hit with almost no bounce or ringing. A possible interpretation is that sensors made with a foam lower disc store and return energy, allowing the piezo to flex (flexing also returns voltage from a disc piezo). This is worth looking into further, but with 24 drums in one array, total crosstalk and transmitted noise from the mounting brackets could become a major issue.

Assemble the cone upside down

This could help with:

• Possible damage to the solder attachments or surrounding material from the powerful adhesive on the bottom of the foam sheet.

The top cone is made of three layers of foam sheeting. By assembling it upside down (with the adhesive layer on top) I can attach the bottom of the cone using the much softer and weaker Bear tape (with a hole cut out for the solder joints and leads). As a bonus I can use the adhesive on the top layer to add some material that protects the tip of the cone that rubs on the mesh drum skin. I made a sensor like this accidentally when I was working out the manufacturing process and it has been working flawlessly on an 8” drum.

This is working just as well as my normal designs. The vibration after the initial impact is interesting but falls well below the threshold of hit detection.

The piezo in this design is sandwiched between two layers of thin, soft and slightly stretchy double-sided tape with a generous cut out for the sloppy factory soldered leads. As usual, the cone base has a channel cut for the leads though this may not be necessary when the cone has no adhesive. I’ll build some more in this design and see what works.

A Note from the Future

Several months after writing this whole page I started experiencing problems with the triggers again, and made a new discovery – the lower adhesive of the Bear tape was necessary for the survival of the piezo (and does allow for the replacement of the foam cones without destroying them), but in the photos above I am using far too much tape on top of the sensor. The tape should only cover the central disc, not the whole unit. I had to perform remedial surgery on all 24 triggers, as shown below. I also added a 330kΩ resistor from the positive of the piezo to the Cliff sockets. This forms a voltage divider with the 1MΩ input resistor that effectively lowers the input by 1-2 Volts, a much more comfortable range for the buffer circuit that follows.

Side mounted sensors

I recently found an old Roland pad in a music shop, a PDX6 or 8, and saw that the sensor in this model was mounted at the rim of the drum, with a flat-topped cylinder of foam contacting the skin. My current practice of mounting a cone shaped sensor in the middle of the drum should guarantee an even response around the drum head but if any hits land on the cone tip, they blast though regular playing at 100% velocity. A side sensor might fix that problem and side-step some of the issues described above that might originate in mechanical stress. A drum head deforms the most in the centre so a side mounted pickup should see much lighter impacts, less flex and less travel overall. I designed some side-mounting fittings and put together test rigs in soft and hard material. These sensors used a pack of smaller 25mm piezos from an earlier project.

I was expecting lower voltages from the side mounted sensors. They were smaller in diameter (25mm vs 37mm) and the side mounting would transmit a lot less of the stick energy to the piezo. I was not expecting numbers this small. The cylinder of soft material was useless, my hardest hits were just touching 0.5V. The harder cylinder was more promising, giving me ~1V, inexplicably negative. The wires were correctly installed on the piezo and correctly connected to the Cliff jack. This piezo just wanted to be different.

From watching a repair video for the PDX8, I can see that the side mounted piezo element in that pad is much closer to the skin than in my far deeper, more drum-like design, with a much shorter cylinder of foam. I also noticed that the replacement foam does not have a channel for the solder attachments, so they do not seem to be concerned that the adhesive will damage the top of the piezo.

The biggest problem I found with side-mounted sensors was a wildly varying sensitivity across the drum skin, with the side opposite to the sensor unplayable. These side sensors appear to need either a larger drum diameter (for more energy) or a much flatter foam column to get more of the impact energy to the piezo.

What About Tension?

That did get me thinking about the role that the drum head tension is playing. For this test I used the under-performing soft cone, to see if I could make it more usable. Tighter heads move less than loose heads, so would loosening the drum heads give my sensors more energy to use?

It does. But not a significant amount considering other variables, such as cone material, can have a much larger impact. In a not-very-scientific test I barely finger-tightened a double thickness mesh skin, measured some strong hits, then tightened the tensioning nuts by a half turn for each test afterwards. It only took two steps to get to the maximum tautness I would want to play with. As can be seen above, the loose skin returned ~2.5V, then just under 2V at medium and ~1.5V at maximum tension. The medium tautness is the loosest skin I would want to actually play, so while these are interesting results, they are not enough to make the soft cone a better sensor than the firm cone for supplying ~5V of velocity sensitivity to an Arduino input or even an Arduino set to 3.3V of input range. I would rather slightly exceed the input ceiling than lose sensitivity to light hits.

Single or Double Ply Heads?

I started this project with high quality Remo Silentstroke single-ply heads. They have not been available in my area for months and I have continued the project with some very quality-challenged Chinese drop-shipped double ply heads. I was curious about the loose 2nd layer of mesh – was it interfering with the operation of the sensors? I ‘converted’ some of these cheap skins into single ply by simply cutting the bottom ply out. No change in voltage readings was observed in the soft or hard foam sensors.

Conclusions

After all of these experiments, what really stands out to me is that all of these sensors worked. That does not give me any new information to help diagnose what went wrong with my last batch, but this shootout leaves me feeling more confident that I am on the right track with my firm, centrally mounted cones on a 37mm piezo and that they will work if I am careful and switch to the upside down cone design for the rest of the drum array.

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.

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

STL Models for Printing

The models used above, and others discussed in other parts of the blog, are available from the project download page.

The information arrived as an STL file. The scan had a good level of detail, but some problems needed to be addressed before I could turn this into a printable model. It has been many, many years since I last used Blender, so I decided to use this project as a re-introduction. I looked for ‘Blendercam‘, the modified version I used to use for creating cutting files for my CNC mills, but there were no valid downloads that would run on my Mac. Vanilla Blender it is then, with Ultimaker Cura as the 3D printing processor.

The raw model was inside out – the inner surface of the model was on the outside, preventing me from turning it into a printable object. I used Autodesk’s Meshmixer to clean up the edges of the mesh and ‘flip’ the faces so the outside was properly outside. I am aware that Blender has similar tools but using Blender is very similar to using Avid’s Pro Tools – it is filled with a seemingly random mix of useful and esoteric functionality that is not navigable until you have spent a few weeks unraveling the interfaces and learning the hotkeys. It is often quicker to use another, simpler tool that is focused on the task you want to achieve. Meshmixer can also turn a surface, like my scan, into an solid object. It does a good job but I was unhappy with the loss of detail in the final model. I imported the fixed mesh back into Blender and manually extruded the scan into an object.

In Blender I used the circle select tool to separate the teeth into objects. I have a very old 3D Connexion Space Navigator that is still supported, even in Monterey on an M1 Mini. Flying around the object with the left hand and controlling selection with the right makes Blender so much easier to use than just a mouse/keypad/keyboard combination. After isolating the teeth I used ‘Fill’ to create new faces, filling the open mesh holes in the teeth and in the gums. Blender’s sculpting tools filled the faces with a dynamic mesh that I could push and pull into shapes that I felt comfortable printing. I added rods to the teeth and subtracted them from the gum object – they will allow me to mount the teeth and run wires into them from underneath the gums.

These pieces were made to be experienced, not watched. Watching an immersive experience from the outside is like eating the menu at a restaurant – but below is a collection of short clips showing the system in action. ‘Coil’ and ‘Living Room’ use the Vive controller as an exploratory tool.

‘Coil’ places you inside a gradually intensifying map of the electromagnetic radiation emitted from consumer devices in a kitchen & lounge room. Discovering the unseen topology of the fields we live with every day is surprisingly visceral.

‘Living Room’ scales Australia down to 3 meters inside the dome. Dynamic maps of bushfire, rainfall and temperature variation can be selected via a bluetooth footswitch. Although you are inside the data projection, an FM modular synthesiser controlled by the position of the Vive handset is your only feedback, growing more discordant as time passes and the maps intensify. Areas without change are the only respite but they grow fewer and smaller as change accelerates.

‘Workspace’ is a subset of tools designed to make a complete VR mixing environment. The spherical audio emitters can be placed in 3 dimensional space, adjusted for volume and given animation paths that they will repeat until reset. Evaluating the efficacy of my DIY Ambisonic dome when combined with immersive headset VR in this manner was the subject of my thesis.

‘Drown’ is simple, largely passive and surprised me with the nasty intensity of the conveyed experience. This work is entirely dependent on the power of visual and audio VR immersion. Seated in the centre of the dome, over several meditative minutes your mind accepts the reality of the undulating wireframe ocean and drifting sound emitters. Then you realise that the level is rising. The moments when the water surface is just at head height and the waves are higher than you can crane your neck are genuinely disturbing.

A slightly redacted version of the artist statement can be downloaded here.

Back in the 70’s you could buy hardware Ambsonic decoders, such as the Integrex. They were niche, and usually available as a kit you built yourself. Reportedly, they did not perform very well though I’d love the opportunity to hear one to judge for myself. The largest drawback of a hardware solution is that you are tied down to one configuration of speakers. Personal computers have become so inexpensive and powerful that it is easier and far more flexible to drive the dome from a software solution.

The ideal software for cost effectiveness is Pure Data, also known as PD. It’s hard to beat free software for price. This is an open-source solution and comes with all of the benefits and drawbacks of an open product. There is a lot of support and a real community around PD, but if it breaks, you get to keep both pieces and there may be no-one interested enough to help you. This is also a good way to describe the current state of Ambisonics in PD, specifically the HOA toolset.

It looks great – it also doesn’t work anymore with the current version of PD and hasn’t worked for years. You could try running it in a version of PD from when it was released, but then you will discover that other parts of PD will not work because they are too old. To borrow a phrase from the Linux community, you are now in ‘dependency hell’ where there is no combination of software versions that will work for everything you want to do.

I’ve run into this problem a lot when developing for Arduino, where it is particularly bad. I often wonder if anyone in the Arduino community actually gets any real-world work done with the products they write about on their webpages. A popular library for processing the output of gyroscopes has an axis completely reversed for some hardware. None of the popular Youtube channels or blogs even noticed and the main library remains unfixed.

With PD reluctantly excluded, we must turn to MAX/MSP and MAX for Live. The HOA tools from PD are also available in MAX, but why make life difficult when the excellent ICST Ambisonics package is available for free in the package manager.

ICST Ambisonics makes a complex job easy. If you know where your speakers are and you know where your sources should be (or you have audio already recorded in a surround format), you can have audio coming out of the array in just a few minutes. My own software stores lists of speaker configurations to suit different rooms. You can select 4, 5, 10, 20, or 25 channels (plus the subs channel).

Unfortunately, MAX/MSP is not an open source product and it is not cheap. I still hope to replace MAX with PD when I have enough time to return to programming for fun, but that time may be never.

Waves NX

Although the dome is portable, transporting it requires several large boxes and about 6 hours of swearing to set it up (if you are on your own). There are some clever tools available to bring something approaching surround sound to your headphones.

Let’s first talk about mix room simulation.

Room simulation tools have been around for a long time. I used to use Focusrite’s VRM (Virtual Room Modelling) until an Apple OSX update made it inoperable. These tools were very polarizing when they were released, many engineers hated they way they sounded. One friend who disliked the effect flipped through the presets, turned it off and on a few times, complaining about how fake and smeared the sound was. If you have the desire to try one of these tools, this is exactly how not to audition one. By turning it off and on and jumping from one room model to another you are concentrating on the differences between the emulation and the reality – you are creating a condition where the emulation cannot win.

At first, I didn’t like the VRM much either, but I left the headphones on and set to work mixing. About fifteen minutes later there was a knock at the studio door and I leapt to the room controls to turn the monitors down. I had been fooled and completely forgot that I wasn’t listening to speakers. The same approach works with Waves NX – don’t dismiss this technology before giving it a fair listen.

Waves NX is step above a static room emulator. It is capable of tracking the movement of your head, either through your laptop’s camera or by using a special bluetooth sender that attaches to the band of your headphones. Some popular headphones have frequency compensation curves built into the plugin. Measure the circumference of you head and the distance between your ears around the back of your head (the inter-aural arc) and Waves NX will use a HRTF (head related transfer function) to calculate what each ear should be hearing as you move your head.

Waves NX is not kind to your processor if you use webcam tracking, and the positional lag as the camera system chases your face wrecks the effect a little (in a similar way to visual lag ruining your Virtual Reality immersion). It does work though, and a slew of competitors are releasing similar products.

DIY 26 Speaker Ambisonic Dome – Part 1, The Dome Structure

DIY 26 Speaker Ambisonic Dome – Part 2, The Audio