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.
In July 2019, inspired/encouraged by a friend name Alice, I bought an electronic drum kit. It was a Roland TD-17KV; I now have the Roland TD-17KVX because I’m a sucker for upgrades.
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.
33 thoughts on “V-Drum Explorer: Introduction”
Awesome, can’t wait to see where this goes. There aren’t a lot of good blogs on the real problems of building a non-trivial application, especially when they connect with 3rd party objects
Very cool! But, no Blazor love?
Not yet, at least…
This has a lot to it. Can’t wait to read.
Also, when you say, “The transition to a full schema,” what do you mean? Schema for what?
The schema for the configuration. It’ll all make sense when I write it up with examples.
Is it (he asks, brimming with hope and anticipation) JSON configuration, and therefore JSON Schema?
No, it’s the drum configuration – for example, knowing what fields there are to configure each instrument.
The schema is in JSON, but it’s not a schema for JSON.
This is a great idea! I’ve been playing for a couple of years on a TD-11KV and am looking forward to seeing what this can do!
Have you played drums before or is this a new adventure?
New adventure. I’m sorry that the V-Drum Explorer won’t work with the TD-11 – it doesn’t support the same protocol as the TD-17 and TD-50. (It’s possible that the “dump it all over USB” functionality would send all the data to the computer, but I don’t think it would be feasible to then modify the module later…)
Ah well, I’ll enjoy it in its native form then! I hope you’re enjoying the drums as an instrument as well as as a hackable device.
LikeLiked by 1 person
Cool project! Music is a fun outlet. Best of luck! Cheers.
The link is slighty incorrect for “part of my demo code GitHub repository”. So it returns a 404 for now. It should be https://github.com/jskeet/DemoCode/tree/master/Drums.
Whoops, thanks, will fix.
Excellent idea! Saves editing the kits through the module. No more “dialing” to edit the kit names!!! Any chance to add support for TD-27, please? I could help with debug, etc.
I have a TD-27 currently in the hands of UPS… part of my excuse for buying it was to support it in the explorer :) So yes, there will definitely be support – it might take a while to sort out the schema, but I’ll get to it as soon as I can.
No rush, first and foremost enjoy your new drums.
Please let me know if I can help in any way.
It’s now available :) See documentation at https://jskeet.github.io/DemoCode/Drums/
What a great idea!!!!
I have a TD-17 in my setup and I am excited by how useful your V-Drum Explorer program would be for me. What I dont know is if you are looking for end users to offer you feedback on using the iterations of the program you have released to date? I am not sure how this whole “github” thing works as it has been about a thousand years since I wrote any code back in Engineering School. lol
In any event V-Drum Explorer scans all my midi ports and correctly detects a TD-17; however, when I go to “Load all data” it gives me an error and won’t load any data?
23:27:07.926 Detecting devices for MIDI ports with name ‘TD-17’
23:27:08.928 Detected single Roland device identity: 17: Roland product 843/0, revision 0
23:27:08.928 Identity matches known schema TD-17.
23:27:08.933 Device detection result: TD-17 detected
23:27:14.057 Loading 10414 containers from device TD-17
23:27:14.060 Failure while loading Current
23:27:14.061 Error loading data from device
As above not sure if this post is appropriate but I thought I would give it a shot as I think this program will be very useful. You should sell it to Roland when you are done!!!! :-)
Thank you for the cool work you have done so far!!
I’m definitely looking for feedback, yes :) It may be best to email me (email@example.com) for more discussion, but one thing to check is that you’ve got the USB mode set to “Vendor” rather than “Generic”. I don’t know for sure whether that would lead to this error, but I wouldn’t be surprised.
(The version of the code that’s used for the latest installer is actually pretty old by now… I need to get on and release a new version soon.)
I think this a quite good project.
To be honest, I think that such a software should be provided by Roland itself, as the desire (or need) of handling kit configurations with a computer interface is, in my opinion, quite… foreseeable (to say the least) when you sell a device saying that it can be connected to a computer for (audio or midi) recording purposes.
So, as a TD-17KV owner and DAW music “maker”, I obviously (and… selflessly :] ) hope that your project can soon achieve its purpose in the best way.
Just a question:
what about a TD-17 connected to the PC via USB cable (and suitable Roland usb driver)?
Is V-Drum Explorer intended to detect it and operate it as well?
Yes, using a USB cable (providing the MIDI connection) is the primary way that this does work… while it can work over the Bluetooth MIDI connection, I’d definitely suggest using USB instead :)
I’m sorry, I forgot that the TD-17 has no midi ports (maybe it’s the Sunday air or maybe some kind of accelerated aging…).
So my question made actually little sense. :]
I take this opportunity, anyway, to make another one, which I hope will be more sensible.
I saw in your documentation that the software is available also in zip form, without an installer.
Does this mean that it can be run in “portable” mode, that is without having it write anything outside its own folder or in the Windows registry?
Yes, I’d expect that to be fine. Once the files are present, it doesn’t write anything anywhere other than the files you choose to save. It’s pretty simple in that respect :)
I’m exploring the possibility of trying to build an equiv app for Mac, the main goal being to be able to update, load, and edit kits with a desktop UI rather than doing the SD-card file hierarchy two-step that is documented. Many years ago I remember using a Mac app to connect to my TD12, but there doesn’t appear to be a modern equivalent for the newer Roland protocols (as you’ve worked on for Windows). I’m building for apples latest architecture so theoretically whatever I could come up with would be able to run on iOS as a bonus. Anyway, this blog and your repo are the closest thing I could find to get started, but I’m struggling to locate the Roland TD-17 document (or better even, 27, which is the module I have, though my understanding is that the interface would be the same). The link in your repo 404s, any tips on where or how to find that? Thanks for your effort, this is awesome.
If you go to https://www.roland.com/uk/support/by_product/td-27/owners_manuals/ then hopefully you’ll see (as I do) a link to the “MIDI implementation” – that’s always the document you need.
Perfect, thanks! How can I submit a feature request? The thing that I miss the most on the TD17 is that I cannot copy an individual instrument with all its settings from one kit to another. The highend modules can do that, but I think they cut this out on purpose on the more “budget” ones like the 17 and lower.
Feature requests are managed at https://github.com/jskeet/democode – I suspect that https://github.com/jskeet/DemoCode/issues/123 may describe what you want, but it may not quite. I can’t promise any quick action on feature requests, but I’ll do what I can when I can :)
Hi Jon !
I hope you’re doing well !
It’s me again who, as in the good old days of the transition to version 1.02 of the TD17 firmware, comes to ask if it will be possible to take into account the new (probably the last one) firmware that Roland has just published: V2 .0
There are obviously still a few additional triggers in the list, which does not fail to upset the order established so far.
+ new functionalities like Compression….
As the previous time, I can easily provide the firmware and also the new list of triggers (we have already done it together!).
I’m still using VdrumExplorer and it’s not going to stop!
I’m definitely happy to look into this, but I doubt that it’ll happen before about February as I’m busy with other things. I should be able to use our church TD-17 for testing the new functionality though.
Sorry for forgetting about this comment – I implemented this in January, so if you get the latest version it should work with the new fields.
Thanks for the quick reply. Of course, I fullyunderstand the current workload. No problem. I am available to help if needed.
Happy Christmas and New Year’s Eve
Thanks for the news and the message for the availability on the update.
I was waiting for your signal, so, no, I didn’t saw the delivery of the update.
Yet downloaded now !
I will use your software soon.
Many thanks for the development
With my best regards