After a lengthy break from DK421 development I started up again this evening. My primary purpose tonight was to learn how to program my arduino and to learn the basics of serial communication with javax.comm. I wrote a led blinker that also sent some data over the serial connection. 0 when it turned the light on, 1 when it turned it off. and yes, I know that seems backwards.

After a short battle I hacked up the config and a sample program to print my data. It’s not printing the right values, but it is printing the wrong ones consistently. I think it has to do with my function to convert a byte array to an integer. It also has a small runtime exception that I didn’t work out. Regardless, it’s working. I’ll install Eclipse on this machine and maybe get it working even further soon. Next step is to get some piezo’s and learn to read them.

On that front I was thinking about using the velocity of an impact to handle the volume it plays back. Maybe something of a code, like if a strike is registered with a strength of 100 on pin 0 it could send 0_100 or something. Thats in the future though. I am worried about the fact that there are only 6 analog pins though. That means 6 drums without adding another board.

After some fantastic hardware work I’ve started yet another rewrite of the software for DK421. This time I’m rebuilding it to use more graphical options and let you load new clips without restarting the whole thing. I’ve been learning a bit in my Java class about all this GUI stuff, so I thought I’d apply it.

I’m still hoping someday I can add a save/load functionality to bring in a while sound set. Not the biggest deal at this point, but it would be a nice convenience. I’ve also gotten the first test drum pad cut and am going to buy the other pieces tomorrow. I might have a working pad by tomorrow evening, though my late classes might have something to say about that. I’m tempted to bring my controller to school and work on it between classes. Probably won’t though. Anyway, DK421 is in the early stages of version 0.03 now, I think it’s time to make it a better project page.

P.S. I’ve set the size for this project: 12 Controllers. So that comes out to 1 hi-hat and up to 9 other pads (cymbals, snares, whatever). More than enough for almost any drum kit. I think my first hardware version will be snare, hi-hat, kick, crash, ride. I’ll probably add toms later.

I’ve been working on my DrumKit again, since I don’t get to play with my Nokia 770. I came up with a better name for this revision, DK421. It doesn’t mean anything. Well, it kinda does. It came from a Stormtrooper in ANH (”TK421, Why aren’t you at your post? TK421, respond.”)

There isn’t a lot of change in this version. I re-read the API for javax.sound.sampled and re-wrote the SoundClip class (formerly KitClip) from scratch. It think it’s cleaner and more usefull for other projects now.

I also added in a file chooser class, DrumChooser so there aren’t any absolute paths in the source anymore. I also added to that class a minor key-fetching function. I hope to make the kit’s expandable, as many drums as you can until you hit a LineUnavailableException.

The GUI hasn’t changed a lick, and I need to clean it up and develop a new layout for it and for the “multiple-drum” expandable version. It’s surprising what you can learn from an API.

I finally started work on my DrumKit project today. Essentially this is an attempt to create a electronic drum set from some pads, an old keyboard and a computer. I got down to buisness and wrote up a Java app that plays back the drum sounds on key press events. It filters them and even handles shift for the hi-hat open/close, which I’ll use to make the hi-hat pedal work.

The source is messy, and still has relative path’s for the sound files. Essentially it’s a frame, a keylistener and some clips. Not too rough, though patching this together from the Java API and sparse information on javax.sound.sampled was tougher than I guessed it would be. Anyway, it’s got some bugs and features not implemented, but I can play drums with my keyboard now, which is a good start.

The Cutting Edge DrumKit GUI

I suppose I should upload the code just in case, and to keep track of my versions. You can get the source and the sounds for Version 0.01 below. As a heads up, all the kit samples are absolute path’d for my machine, so you’ll need to adjust them if you intend to compile it.
» DrumKit001.tar.gz - Everything
» DrumKit.java - Main class
» KeyHandler.java - Event listener
» KitClip.java - Kit sample class

I just wrote the following line of code as part of an implementation of a bucket sort.

bucket[(array[j]/static_cast<int>(pow(10.0,y)))%BUCKETS].Enqueue(array[j]);

Somehow I feel wrong inside about it. Look at it, it’s fairly complicated. In the context of the program you could work out what it was doing, but the effort would be made easier if it was rewritten as this.

int temp = ( array[j] / static_cast<int>( pow(10.0, y) ) ) % BUCKETS;
bucket[temp].Enqueue(array[j]);

Just splitting up that nasty math part from the method call clear up a bit of the ambiguity of what the line is doing, and the next version is even better.

1
2
3
4
5
6
7
8
9
10
11

// Returns a set number of digits from an
// integer in the array, based on the number
// of buckets and the current iteration.
// For example:
//     array[j] = 123456;
//     y = 4;
//     BUCKETS = 100;
// Then:
//     temp = 12;
int temp = ( array[j] / static_cast<int>( pow(10.0, y) ) ) % BUCKETS;
bucket[temp].Enqueue(array[j]);

While this doesn’t really tell you whats going on, it can lead you to finding the pattern involved. That pattern is described thus:

For an integer N, the digit X positions to the left of the least significant digit is: (N/10^X)%(10^Y) Where Y is a “look-ahead” to retrieve the next-Y digits as well.

Thats my informal definition mix for base 10 numbers, derived from a few dozen minutes of fighting with bc. I could put this information into the program, and then deciphering it’s workings would be a snap. But why? I mean, I’m never going to use this again, and if I need to, I worked it out the first time, the second shouldn’t be any harder. How much documentation is too much? How much is too little?

I hate bloated files, sources that are so filled with comments you never see any code. I think (like many before me) that code should be self-documenting as much as possible. I don’t belive in using in-line comments. They get in the way and don’t often help. But I’ve also always thought you shouldn’t break out the comment blocks for anything that wasn’t “serious”, so do I lower the definition of a “serious” comment, or do I throw away my would-be in-liners?

I suppose this is one of those things that comes with time, but I’ve tried to maintain old code before, that someone else wrote with zero comments, and it’s impossible. I think I’ll err on the side of caution, for whoever comes after me.