This is the first in what I expect to be quite a long series of blog posts, meandering over a fairly wide range of topics as they crop up. There’s nothing particularly technical in this introductory post. It’s really just a starting point.
Both of these are kits using the TD-17 as the module. That’s the part of an electronic drum kit that turns electrical signals from the triggers on the pads into sound and/or MIDI messages. The module is sometimes known as the “brain” of the kit. There’s quite a lot of terminology involved in electronic drum kits, and I suspect I’ve barely scratched the surface in the few months since I’ve started.
The TD-17 series is just one option within a suite of products called Roland V-Drums. The TD-17 is currently the most recent part of this suite. It’s a mid-tier product; currently the high-end kit is the TD-50 and the entry level is the TD-1. When I was choosing between the TD-1 and thd TD-17 (with the TD-50 never being an option) I was basically drawn to the greater flexibility of the TD-17 module over the TD-1. I didn’t know how feasible it would be to configure it programmatically, but it at least felt like something I’d have fun investigating.
Configuring a TD-17
In order to understand why I was even considering coding for this, it’s worth having a look at what you can configure on the TD-17 module.
There are a few top-level things you rarely need to configure, such as which triggers you have attached to the module. Most of the configuration happens within a kit – and there are lots of kits. Now this is already slightly confusing because right at the start I talk about buying an “electronic drum kit”. The term is effectively overloaded, unfortunately, but most of the time in this blog series I’ll be using the term “kit” in the sense it’s used within the module.
The TD-17 supports 100 kits. There are 50 presets, and 50 user-defined kits. There’s no real difference between the presets and user-defined kits in terms of what you can do with them – you can think of it as “There are 100 kits available, but Roland got bored after creating 50 of them and left the other 50 in a default configuration.” A single kit is selected at a time, and this controls everything about how the drums sound.
At the top level of a kit, you can configure:
- Its name and volume
- The instruments (this is going to be another overloaded term)
- Its MIDI configuration (which MIDI instruments are triggered)
- Its ambience (simulations for being in a concert hall, or arena etc)
- Its MultiFX (sound effects such as reverb)
There are 20 “instruments” to configure – one for the kick pedal, two for most other triggers (snare, toms, crash cymbals, hi-hat, and a general purpose aux), and three for the ride cymbal. There are two instruments for most triggers because you can configure the head and the edge/rim separately – as an extreme example, you could set the crash cymbal to sound like a gong when you hit the rim, and a snare drum when you hit the head. You probably wouldn’t want to, but you could.
For each of these instruments, you can set:
- The left/right pan (primarily for playing with headphones, so everything sounds like it’s in the right place)
- Equalizer settings (low/medium/high frequency response)
- The instrument (this is the overloading…) – for example “13 inch maple tom”
- The “sub-instrument” which is a second instrument layered under the first (e.g. the first preset kit has a beech kick with a sub-instrument of a deep shell kick) and how the two instruments are layered together
- How much the ambience and sound effects affect this particular instrument
Each main/sub instrument then has its own extra tweaks in terms of tuning/size, muffling, and snare buzz – depending on the instrument.
Of course, you can just play the TD-17 with the preset kits, never going into any of this. But I saw possibilities… the user interface is designed very well considering the physical constraints, but I tend to think that complex configuration like this is more easily managed on a computer.
And so the idea of the V-Drum Explorer was born. Of course, it’s open source – it’s part of my demo code GitHub repository. There’s even documentation with screenshots so you can get the general idea, and a Windows installer downloadable from the GitHub releases page.
From the very start, I imagined a user interface with a tree view on the left and details on the right. It’s possible that by thinking of that from that early on, I’ve missed out on much better UI options.
This blog series is partially a diary of what I’ve done and the challenges I’ve faced, and partly a set of thoughts about how this affects professional development.
I expect to blog about:
- The MIDI protocol used to communicate with the TD-17
- The configuration data model
- The challenges of 7-bit addressing
- Enabling Hi-DPI for .NET Core 3 WinForms apps
- Initial code vs schema considerations
- The transition to a full schema
- Displaying data more usefully: the logical tree
- Working with real users: remote diagnostics
- Immutabilty and cyclic references
- Performance: WPF vs WinForms
- Performance: field instances
- Code signing
- Windows installers
- (Maybe) Xamarin and BLE MIDI
- Moving back from schema JSON to code for ViewModels
That’s likely to take a very long time, of course. I hope it proves as interesting to read about as it has been to implement.